Unhelpful syntax error when expression spans multiple lines

[lazka]

BPO	42577
Nosy	@gvanrossum, @aroberge, @lazka, @lysnikolaou, @pablogsal
Superseder	bpo-40813: Line number of SyntaxError

^{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 = <Date 2020-12-15.18:50:56.492>
created_at = <Date 2020-12-05.15:10:38.712>
labels = ['3.9']
title = 'Unhelpful syntax error when expression spans multiple lines'
updated_at = <Date 2020-12-15.18:50:56.491>
user = 'https://github.com/lazka'

bugs.python.org fields:

activity = <Date 2020-12-15.18:50:56.491>
actor = 'gvanrossum'
assignee = 'none'
closed = True
closed_date = <Date 2020-12-15.18:50:56.492>
closer = 'gvanrossum'
components = []
creation = <Date 2020-12-05.15:10:38.712>
creator = 'lazka'
dependencies = []
files = []
hgrepos = []
issue_num = 42577
keywords = []
message_count = 6.0
messages = ['382566', '382893', '382894', '383023', '383049', '383090']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'aroberge', 'lazka', 'lys.nikolaou', 'pablogsal']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '40813'
type = None
url = 'https://bugs.python.org/issue42577'
versions = ['Python 3.9']

[lazka]

I don't know if the bug tracker is the right place for this, please point me to the right place if not.

Someone faced to the following code (simplified example here) and asked for help:

if 3:
    if 1:
        print(((123))

if 2:
    print(123)

This results in the following error:

File "error.py", line 5
  if 2:
      ^
SyntaxError: invalid syntax

which is very confusing to users not familiar with generator expressions.

I'm wondering if python could improve syntax errors in this case by adding more context, like point to where it started parsing the current thing and where it gave up instead to just the later.

[aroberge]

I suspect that the Python parser cannot easily be changed to given any other message. Replace the colon by "else" and add one more closing parenthesis and you have a valid Python program. So, is it a matter of an unclosed parenthesis, or not using "else" ? ....

If you want possible additional help in such situations, you can try to use the third-party package friendly-traceback which gives the following information for this case (I put your code in a file named "ignore.py")

====

Traceback (most recent call last):
  File "ignore.py", line 5
    if 2:
        ^
SyntaxError: invalid syntax

A `SyntaxError` occurs when Python cannot understand your code.

Python could not understand the code in the file
'ignore.py'
beyond the location indicated by --> and ^.

   2:     if 1:
   3:         print(((123))
   4:
-->5: if 2:
          ^
   6:     print(123)

    I make an effort below to guess what caused the problem
    but I might guess incorrectly.

    The opening parenthesis `(` on line 3 is not closed.

        3:         print(((123))
                        ^

[lazka]

I would expect Python to print the current statement up to the error instead of just the last line:

File "error.py", line 3-5
          print(((123))

  if 2:
      ^

This would solve this case nicely while in the common case still show one line as before.

[lysnikolaou]

Thanks for opening an issue here, Christoph. This is the right place to discuss this.

Indeed the parser is pretty dumb when reporting errors. In the technical sense the colon is the right thing to point to, since it's the first token that's not grammatically correct. Of course, it's somewhat misleading that it points to a line that *seems* correct, but that probably as good as we can do with the parser's current error reporting mechanisms.

Showing more that one lines would indeed solve this specific case, but implementing this is also difficult and I don't think it's worth it for such an edge case.

Guido, Pablo, your views on this?

[pablogsal]

I concur, handling also multi-line constructs is tricky and I would prefer not to implement some hack for specific situations because my experience is that balancing that with other things Is tricky. As Lysandros mentioned, the parser reports correctly the location of the error as indentation is non important inside parentheses and the code there could be an expression or the begging of a generator.

On the other hand we could think if we have a way of detecting of a syntax error occurs in the context of an unclosed parentheses and maybe do something about it, but I have no idea still how many false negatives could appear.

[gvanrossum]

I think something should probably be done about this, but opening another tracker issue is not the way to make progress here. So I am closing the issue. It will happen in due time. No need to have more open issues.