Given the following code containing no if expression (only if statements):

if True:
    print('hello'

if 2:
    print(123))

The following traceback is generated in Python 3.10.0RC1

File "...\example.py", line 2
print('hello'
^^^^^^^
SyntaxError: expected 'else' after 'if' expression

Oh, this is a difficult one.

It's caused by #71693 that was recently added to produce better errors for things like print('hello' if something), where the correct syntax is `print('hello' if something else 'hi').

This is going to have a lot of false positives though, especially in cases like this, where an if statement immediately follows a line with unclosed parentheses.

What do you think, Pablo? Should we maybe revert this?

This is a tricky one because the tokenizer doesn't see the enclosed parentheses because is actually closed (the second print has two
')' parentheses).

This is tricky indeed because the parser is parsing the ( after the print as a group, not as a call, and indentation doesn't matter in the group.

We can indeed revert the PR but I'm afraid that you can use this pattern to actually trigger a bunch of other custom error messages where they should not.

I have no idea how the parser works ... but when you do the test to identify if an 'else' is missing, could the fact that there is a colon instead of the expected 'else' be used to avoid misidentifying this case?

Note: I am keenly aware of the difficulties in identifying possible cause of syntax errors and do appreciate the many improvements that have been done.

Technically this example si more or less equivalent to:

[ something, blech

if 42:
   True

[Bluch]]

I wonder if the better fix here is just not to raise the rule if we find a ':', which is the only token that actually makes sense after

'if' expression

but when you do the test to identify if an 'else' is missing, could the fact that there is a colon instead of the expected 'else' be used to avoid misidentifying this case?

Yeah! That is what I was thinking. The key here is that the ':' is the only token that is valid after the construct, so anything else is a wrong 'if' expression, no matter what it is.

Opened #27615

New changeset f5cbea6 by Pablo Galindo Salgado in branch 'main':
bpo-44838: Refine the custom syntax errors for invalid 'if' expressions (GH-27615)
f5cbea6

New changeset b1bd16c by Pablo Galindo Salgado in branch '3.10':
[3.10] bpo-44838: Refine the custom syntax errors for invalid 'if' expressions (GH-27615). (GH-27616)
b1bd16c