Skip to content
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

Closed
MeGaGiGaGon opened this issue Dec 4, 2024 · 10 comments
Closed

[ruff] Formatting hex codes changes output with f-string debug #14766

MeGaGiGaGon opened this issue Dec 4, 2024 · 10 comments
Labels
bug Something isn't working formatter Related to the formatter

Comments

@MeGaGiGaGon
Copy link

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'=}" gives f"{r'\xff'=}"

>>> f"{r"\xFF"=}"
'r"ÿ"=\'\\\\xFF\''
>>> f"{r"\xff"=}"
'r"ÿ"=\'\\\\xff\''
@MichaReiser
Copy link
Member

MichaReiser commented Dec 4, 2024

Oh that's a nice find!

Funny enough, this is fixed in the new preview style playground

@dhruvmanila
Copy link
Member

Is this a bug in the CPython parser? Why does it parse the hex code even though it is a raw string?

❯ uv run --python=3.12 python
>>> import ast

>>> f"{r"\xFF"=}"
'r"ÿ"=\'\\\\xFF\''

>>> print(ast.dump(ast.parse(r'f"{r"\xFF"=}"'), indent=2))
Module(
  body=[
    Expr(
      value=JoinedStr(
        values=[
          Constant(value='r"ÿ"='),
          FormattedValue(
            value=Constant(value='\\xFF'),
            conversion=114)]))],
  type_ignores=[])

>>> r"\xFF"
'\\xFF'

@MichaReiser
Copy link
Member

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 repr(expr)

I somewhat suspect that python parses everything before the = as a regular string and uses that in the debug expression because Python can't go back to the source for an expression, unlike we can.

@dhruvmanila
Copy link
Member

You mean why the hex code is interpreted in the debug expression?

Yes

I somewhat suspect that python parses everything before the = as a regular string and uses that in the debug expression because Python can't go back to the source for an expression, unlike we can.

Yeah, that's what I thought as well but it's a bit surprising.

@MichaReiser
Copy link
Member

Yeah, that's what I thought as well but it's a bit surprising.

Definitely. It's not what I expected.

@dhruvmanila
Copy link
Member

Should this be closed as it's "resolved" on main ?

@MichaReiser
Copy link
Member

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.

@MichaReiser
Copy link
Member

Let me add a test for this :)

@dscorbett
Copy link

Is this a bug in the CPython parser?

I think so: I opened python/cpython#124363.

@MichaReiser
Copy link
Member

MichaReiser commented Jan 7, 2025

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working formatter Related to the formatter
Projects
None yet
Development

No branches or pull requests

4 participants