I just noticed a subtle discrepancy between the old parser and the PEG parser.

Consider this syntax error:

if x {a}: pass

The old parser places the caret at the '{':

$ python3.8 -c 'if x { a } : pass'
  File "<string>", line 1
    if x { a } : pass
         ^
SyntaxError: invalid syntax

The PEG parser puts it at 'a':

$ python3.10 -c 'if x { a } : pass'
  File "<string>", line 1
    if x { a } : pass
           ^
SyntaxError: invalid syntax

I don't think we should put much effort into fixing it -- it's just a curiosity. I suspect it's got to do with some lookahead.

I had a look at this. I have been testing with the input a{x}, which faces the same problem.

It's actually because of an invalid_* rule. The call stack looks like this:

...
invalid_comprehension_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:15065)
genexp_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:11381)
primary_raw(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:10361)
primary_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:10285)
await_primary_rule(Parser * p) (/home/lysnikolaou/repos/cpython/Parser/parser.c:10240)
...

The invalid_comprehension rule acecpts an LBRACE as the starting token and only fails after it's parsed it, which means that the parser fails with three tokens in the tokens array, the NAME which is valid, the LBRACE which is parsed for the invalid_comprehension rule and the NAME thereafter, upon which the parser fails and backs out of everything. Then, we look at the last token we've parsed and that's where we're placing the caret.

Because of invalid_comprehension, we can even go as far as making the parser show a completely different error, for example:

➜ cpython git:(master) ✗ cat a.py
a{*x for x in a}
➜ cpython git:(master) ✗ ./python a.py
File "/home/lysnikolaou/repos/cpython/a.py", line 1
a{*x for x in a}
^
SyntaxError: iterable unpacking cannot be used in comprehension

Or place the caret even further:

➜ cpython git:(master) ✗ cat a.py
a{*x + a + b + c}
➜ cpython git:(master) ✗ ./python a.py
File "/home/lysnikolaou/repos/cpython/a.py", line 1
a{*x + a + b + c}
^
SyntaxError: invalid syntax

There's a simple fix, which is adding an alternative to the primary rule, that parses something along the lines of primary set and then call RAISE_SYNTAX_ERROR_KNOWN_LOCATION there, but that would have to come before the genexp alternative, which worries me because of the performance implications. primary is a left recursive rule that gets called VERY often, probably more than a few times even when parsing a single NAME.

New changeset 15acc4e by Lysandros Nikolaou in branch 'master':
bpo-41659: Disallow curly brace directly after primary (GH-22996)
15acc4e

New changeset c4b58ce by Lysandros Nikolaou in branch '3.9':
[3.9] bpo-41659: Disallow curly brace directly after primary (GH-22996) (bpo-23006)
c4b58ce