Open akx opened 1 year ago
Let's put these in FLY
(but we should do a quick check to verify that FLY
isn't used by any other popular plugins). Then, we can mark UP031
and UP032
as aliases of FLY
rules once we support rule aliasing, so all the string upgrade stuff is in one place (or vice versa -- add FLY
rules that alias the UP
rules).
Separately, have you been using UP031
and UP032
much? Any issues in practice? Any notable false negatives? There are a few cases we don't yet fix (e.g., if you put the %
in a percent-formatted string on its own line, we abort to avoid wonky formatting).
Separately, do you have an opinion on whether UP031
and UP032
should always flag %
and .format
calls? Or only flag the ones it can fix? Right now, it does the latter. But doing the former would effectively implement #2097.
I have UP031 and UP032 enabled by way of select = "UP"
and haven't seen any issues yet! 👍
Maybe (and this is tangential to the #2142 RUF005 discussion) UP03[12] should have a "suggestion" flag for %
and .format
they can't auto-fix, like "Consider using an f-string".
That said, I could see it being a nuisance if we had to noqa places like "foo {bar} {baz}".format(**something_dynamic)
(though that's better served by format_map
anyway), or "foo %(bar)s %(baz)s" % something_dynamic
)...
Idk if transform-concats
/FLY001
is always desirable on only two items. Especially given possible overrides of __add__
and __radd__
. And it's not even more concise.
But for 3 items, especially when a variable is inserted between two strings*, is definitely something I've been looking for.
* I think it's safe to expect people shouldn't be writing code where "a" + b + "c"
does not return a string using b's string representation. Or just not use FLY001
at that point.
I'm also for keeping these different rules. Makes adoption easier, especially when gradually linting or if a rule's style change is undesired.
flynt
is a specialized linter for f-string usage.UP031 and UP032 implement
flynt
's core features, but the two extra transformsi.e.
and
respectively could be implemented in Ruff too. (I'd like to work on them! 😄) Should these be
FLY
series, or should they beRUF
?FLY001
: consider replacing string concatenation with f-stringFLY002
: consider replacing static string joining with f-string (#4196)Refs https://github.com/charliermarsh/ruff/issues/2097 (relating to f-strings)