-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ruff
] Formatting hex codes changes output with f-string debug
#14766
Comments
Oh that's a nice find! Funny enough, this is fixed in the new preview style playground |
Is this a bug in the CPython parser? Why does it parse the hex code even though it is a raw string?
|
You mean why the hex code is interpreted in the debug expression? I don't know. It is surprising and I couldn't find anything in the f-string lexing section indicating why it should (it only says that it calls I somewhat suspect that python parses everything before the |
Yes
Yeah, that's what I thought as well but it's a bit surprising. |
Definitely. It's not what I expected. |
Should this be closed as it's "resolved" on |
We could. I kept it open to make it clear it's part of the Ruff 2025 style guide and it requires fixing if we, for whatever reason, decide not to stabilize f-string formatting. |
Let me add a test for this :) |
I think so: I opened python/cpython#124363. |
I'll close this because we're about to release the new style guide and I'm sure I forget to close it otherwise. Look out for the 0.9 release ;) |
I had this idea while reading psf/black#4522 when @MichaReiser said ruff had already stabilized hex code formatting.
I don't actively use ruff/am not familiar with it, but I assume that just like black formatting code should not have an observable runtime effect.
playground link formatting
f"{r'\xFF'=}"
givesf"{r'\xff'=}"
The text was updated successfully, but these errors were encountered: