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
This is happening because each f-string element is analyzed individually. So, first TOTAL: is analyzed, then \nOK: and then \INCOMPLETE: , but the checker isn't aware that one of the element contains a newline character.
…e (W605)` (#14748)
When fixing an invalid escape sequence in an f-string, each f-string
element is analyzed for valid escape characters prior to creating the
diagnostic and fix. This allows us to safely prefix with `r` to create a
raw string if no valid escape characters were found anywhere in the
f-string, and otherwise insert backslashes.
This fixes a bug in the original implementation: each "f-string part"
was treated separately, so it was not possible to tell whether a valid
escape character was or would be used elsewhere in the f-string.
Progress towards #11491 but format specifiers are not handled in this
PR.
Update: The issue in the original post has been resolved, but I'm leaving this open because invalid escapes in format specifiers are not handled yet (see #14748 (comment) and the surrounding discussion).
Python: 3.12.3
Version: ruff 0.4.4
Command:
ruff check --select W605 .\test.py --fix
And let's given the following code snippet in
test.py
:It is wrongly fixed as:
Now the string is a raw string. The newlines will then interpreted as literals and will not remain newlines.
If I do the same for a normal string:
It is correctly fixed as:
The invalid escape sequence '\I' is correctly fixed as
\\
, and the newlines are still there.Even if it is a f-string, but without placeholders, it is done correctly:
Result is correct:
The text was updated successfully, but these errors were encountered: