Skip to content

fix(tokenize): keep a backslash from swallowing an f-string field - #251

Closed
Cherith1222 wants to merge 2 commits into
davidhalter:masterfrom
Cherith1222:fix/207-fstring-backslash-brace
Closed

Cherith1222 wants to merge 2 commits into
davidhalter:masterfrom
Cherith1222:fix/207-fstring-backslash-brace

Conversation

@Cherith1222

Copy link
Copy Markdown

Why

rf"\{foobar:>3o}" is valid Python. It evaluates to a backslash plus the formatted value. parso treated that backslash as escaping the brace, so parse(..., error_recovery=False) raised ParserSyntaxError on the closing brace.

What changed

  • An f-string escape now matches a backslash before { without consuming the brace.
  • \N{SNOWMAN} and a failed name such as \N{ BULLET } stay on the old path.
  • Regression cases cover raw strings, format specs, and a triple-quoted string.

Scope

  • Covers a backslash immediately before a replacement field.
  • Leaves the pep8 normalizer crash on a backslash-newline comment alone.
  • Does not change format-spec rules.

Tradeoffs

A bare backslash alternative also matched a failed \N escape and made f"\N{ BULLET }" parse. The pattern uses a lookahead so the extra match applies only when { is next.

Blast Radius

Callers that parse f-strings, including Jedi, now accept this form instead of reporting a syntax error. The existing escape and invalid-name tests still pass.

Verification

  • Before the fix, test_valid[rf"\\{foobar:>3o}"] failed with ParserSyntaxError on } at column 15.
  • After the fix, py -3.13 -m pytest -q reported 1993 passed.
  • The reported snippet parses, and get_code() returns the same source.

Fixes #207

Drafted with Cursor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

KeyError: ReservedString(})

2 participants