SyntaxError in Python 3.10.0b1: wrong token for missing comma

[aroberge]

BPO	44181
Nosy	@aroberge, @lysnikolaou, @pablogsal

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-05-19.21:22:04.958>
labels = ['interpreter-core', 'type-bug', '3.10']
title = 'SyntaxError in Python 3.10.0b1: wrong token for missing comma'
updated_at = <Date 2021-05-19.21:22:04.958>
user = 'https://github.com/aroberge'

bugs.python.org fields:

activity = <Date 2021-05-19.21:22:04.958>
actor = 'aroberge'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Parser']
creation = <Date 2021-05-19.21:22:04.958>
creator = 'aroberge'
dependencies = []
files = []
hgrepos = []
issue_num = 44181
keywords = []
message_count = 1.0
messages = ['393976']
nosy_count = 3.0
nosy_names = ['aroberge', 'lys.nikolaou', 'pablogsal']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue44181'
versions = ['Python 3.10']

[aroberge]

When forgetting a comma in writing a dict literal spanning multiple lines,
the "bad token" is wrongly idenfied with Python 3.10.0b1.

>>> a = {'a': 1
...      'b': 2
  File "<stdin>", line 1
    a = {'a': 1
              ^
SyntaxError: invalid syntax. Perhaps you forgot a comma?

Previously, this was shown:

>>> a = {'a': 1
...      'b': 2
  File "<stdin>", line 2
    'b': 2
    ^
SyntaxError: invalid syntax

However, I hasten to add that the new hint about a missing comma is spot on,
and likely to be extremely useful.

Note: this is based on my "intuition" built from previous version where the token identified by ^
was the first token that the Python parser was not able to make sense of.
Now that the parser highlight a range (if relevant tokens are on a single line),
it makes sense to include tokens preceding the "bad token".
However, when we have an error where such range
spans multiple lines, it can create "problems" such as that shown above.

Perhaps this is not worth attempting to fix and Python programmers like me will have to develop a "new intuition" in such cases (and "fix" friendly so that it can figure out the correct "bad token"
independently of cPython's information)
... and this bug report can be simply closed.

[pablogsal]

I'm closing this as I think that although it may be a bit worse, the error is clear once both lines are examined. If in the future we add the capability to the PEG parser to show multiple lines in syntax errors we can revisit it.