[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Change by Lysandros Nikolaou :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Lysandros Nikolaou  added the comment:


New changeset c4b58cea4771afc0ddfdb857b0fb5115b9f4bc9f by Lysandros Nikolaou in 
branch '3.9':
[3.9] bpo-41659: Disallow curly brace directly after primary (GH-22996) (#23006)
https://github.com/python/cpython/commit/c4b58cea4771afc0ddfdb857b0fb5115b9f4bc9f


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Change by Lysandros Nikolaou :


--
pull_requests: +21921
pull_request: https://github.com/python/cpython/pull/23006

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Lysandros Nikolaou  added the comment:


New changeset 15acc4eaba8519d7d5f2acaffde65446b44dcf79 by Lysandros Nikolaou in 
branch 'master':
bpo-41659: Disallow curly brace directly after primary (GH-22996)
https://github.com/python/cpython/commit/15acc4eaba8519d7d5f2acaffde65446b44dcf79


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Change by Lysandros Nikolaou :


--
pull_requests: +21910
pull_request: https://github.com/python/cpython/pull/22996

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Change by Lysandros Nikolaou :


--
pull_requests:  -21195

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Change by Lysandros Nikolaou :


--
keywords: +patch
pull_requests: +21195
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22111

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Minimal example
>>> a{ # or
>>> a {
In 3.8, this is immediately flagged as a SyntaxError.  In 3.9 and master, a 
continuation prompt is issued.  This strikes me as a parsing buglet that should 
preferably be fixed, as it implies that something valid *could* follow '{', 
thus misleading beginners.  On the other hand, after scanning my keyboard, '{' 
seems unique in being a legal symbol, unlike `, $, and ?, or combinations like 
+*, that can AFAIK never follow a name.  So it would need special handling.


Side note: for the same reason I dislike the { change, I like the generic 3.9 
change for legal operators without a second operand. 
>>> a *
Both flag as SyntaxError, but in 3.8, the caret is under '*', falsely implying 
that '*' cannot follow a name, while in 3.9, it is under the whitespace 
following, correct implying that the * is legal and that the problem is lack of 
a second expression (on the same line without continuation).

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Lysandros Nikolaou]

Lysandros Nikolaou  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Chrome]

Change by Chrome :


--
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Chrome]

Change by Chrome :


--
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41659] PEG discrepancy on 'if {x} {a}: pass'

[Guido van Rossum]

New submission from Guido van Rossum :

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 "", line 1
if x { a } : pass
 ^
SyntaxError: invalid syntax
```
The PEG parser puts it at 'a':
```
$ python3.10 -c 'if x { a } : pass'
  File "", 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.

--
assignee: lys.nikolaou
messages: 376048
nosy: gvanrossum, lys.nikolaou
priority: low
severity: normal
stage: needs patch
status: open
title: PEG discrepancy on 'if {x} {a}: pass'
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com