You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like the idea of F109 (I've wanted something like this for over 6 years, see pylint-dev/pylint#1001 😅)! However, my codebase currently somewhat consistently uses lists (given that I mostly see lists for homogenous data, but tuples for heterogenous data).
Due to that, I'd have to disable this checker currently - it'd be nice if there was a way to configure it to assume lists (and maybe sets) instead. Even its description seems to imply that there's no one true choice ("it is best to pick one and stick with it").
The text was updated successfully, but these errors were encountered:
See #44. Basically, with lists and tuples, there is no difference at the bytecode level (originally I assumed that tuples would be faster, which wasn't correct). sets on the other hand will be faster for larger datasets, since lookups are O(1). Because of this, sets emit different bytecode.
To answer your question though, I do think I users should be specify whether they want to use []/()/ {} formatting, but there currently is no way to pass arbitrary data to a check.
To fix this, we could implement something like this for the command line:
refurb file.py --data FURB109.style=list
And something like this for the config file:
[tool.refurb]
# your settings here
[tool.refurb.data.FURB109]
style = "list"
Then, when running the FURB109 check, we would pass in the key values that the user supplied (if any). The check would be free to do what it wants with the data (though we would want to document this for the user).
I like the idea of F109 (I've wanted something like this for over 6 years, see pylint-dev/pylint#1001 😅)! However, my codebase currently somewhat consistently uses lists (given that I mostly see lists for homogenous data, but tuples for heterogenous data).
Due to that, I'd have to disable this checker currently - it'd be nice if there was a way to configure it to assume lists (and maybe sets) instead. Even its description seems to imply that there's no one true choice ("it is best to pick one and stick with it").
The text was updated successfully, but these errors were encountered: