Incorrect SyntaxError location for walrus operator in multi-line conditional expression

[zrekryu]

Bug report

Bug description:

When using the walrus operator (:=) inside a multi-line conditional expression, Python raises a SyntaxError with the error position pointing to the wrong location.
The caret (^) is shown under the expression body instead of the if clause where the syntax issue actually occurs, making debugging misleading.
The error indicator should instead highlight the if portion (or walrus usage context), not the preceding expression line.

Code

(
    1
    if x := True
    else 2
)

Traceback

File "[REDACTED]", line 2
    1
    ^
SyntaxError: expected 'else' after 'if' expression

It locates error to 1 but it should have located to if x := True (line no. 3)

It does not errors when condition is parenthesized:

(
    1
    if (x := True)
    else 2
)  # output: 1

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Linked PRs

• gh-146260: Improve syntax error for assignment expression inside conditional expression #146305

[gvanrossum]

But that's allowed in if statements. Why not in if expressions?

[brianschubert]

Likewise in the else expression:

(
    1
    if 2
    else x := 3
)

which gives:

  File "<python-input-1>", line 2
    1
    ^
SyntaxError: cannot use assignment expressions with conditional expression

(which makes sense given that this is parsed as (1 if 2 else x) := 3, but it could be clearer if the error highlighted :=)

[picnixz]

So you suggest highlighting the walrus misusage here and reuse the same error message as with the else case?

[brianschubert]

I think the case I brought up is actually not very related and should probably be discussed separately (it's also less clear to me that changing it would be an improvement).

For the OP's case, I find the error somewhat confusing even when the whole expression is on a single line:

>>> 1 if x := True else 2
  File "<python-input-5>", line 1
    1 if x := True else 2
    ^^^^^^
SyntaxError: expected 'else' after 'if' expression

so I think this could definitely benefit from a specialized error message.

Maybe something like "assignment expression must be parenthesized inside conditional expression", which highlights the inner assignment expression? (not a parser expert, so I don't really know how doable that is)

[picnixz]

I can't remember the exact rule being involved here so let's ask @pablogsal

[brianschubert]

The current error is generated by this alternative, so I think we could add a specialized error for this case by adding an alternative just before it. This seems to do the trick locally:

diff --git a/Grammar/python.gram b/Grammar/python.gram
index 3a91d426c36..9ee350ae3d4 100644
--- a/Grammar/python.gram
+++ b/Grammar/python.gram
@@ -1264,6 +1264,8 @@ invalid_expression:
     # Soft keywords need to also be ignored because they can be parsed as NAME NAME
    | !(NAME STRING | SOFT_KEYWORD) a=disjunction b=expression_without_invalid {
         _PyPegen_raise_error_for_missing_comma(p, a, b) }
+   | disjunction 'if' a=disjunction ':=' b=disjunction {
+        RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "assignment expression must be parenthesized inside conditional expression" ) }
    | a=disjunction 'if' b=disjunction !('else'|':') { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "expected 'else' after 'if' expression") }
    | a=disjunction 'if' b=disjunction 'else' !expression {
         RAISE_SYNTAX_ERROR_ON_NEXT_TOKEN("expected expression after 'else', but statement is given") }

but I'd like to hear a parser expert's thoughts on if this is the right direction to go.

[gvanrossum]

Something's really weird with the relative priorities of walrus and if-else here.

[picnixz]

For the 1 if 2 else x := 3 I would say it makes sense to parse it as (1 if 2 else x) := 3 but I do find it odd that 1 if x := 3 else y is parsed as 1 if x and then we expect else rather than allowing a possible named expression.

Nevermind this comment.

[pablogsal]

I can't remember the exact rule being involved here so let's ask @pablogsal

Yeah, what's happening here is that when running the invalid rules the matches first and triggers because the general parser run failed so the first 'invalid' rule that matches that area wins. We either need to add more to that rule to reject this situation and don't trigger or add a new one that matches first

[brianschubert]

We either need to add more to that rule to reject this situation and don't trigger or add a new one that matches first

Tweaking the rule to reject this situation with something like:

diff --git a/Grammar/python.gram b/Grammar/python.gram
index 3a91d426c36..4d8a0561c97 100644
--- a/Grammar/python.gram
+++ b/Grammar/python.gram
@@ -1264,7 +1264,7 @@ invalid_expression:
     # Soft keywords need to also be ignored because they can be parsed as NAME NAME
    | !(NAME STRING | SOFT_KEYWORD) a=disjunction b=expression_without_invalid {
         _PyPegen_raise_error_for_missing_comma(p, a, b) }
-   | a=disjunction 'if' b=disjunction !('else'|':') { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "expected 'else' after 'if' expression") }
+   | a=disjunction 'if' b=disjunction !('else'|':'|':=') { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "expected 'else' after 'if' expression") }
    | a=disjunction 'if' b=disjunction 'else' !expression {
         RAISE_SYNTAX_ERROR_ON_NEXT_TOKEN("expected expression after 'else', but statement is given") }
    | a[stmt_ty]=(pass_stmt|break_stmt|continue_stmt) 'if' b=disjunction 'else' c=simple_stmt {

results in a pretty opaque syntax error:

>>> (
...     1
...     if x := True
...     else 2
... )
... 
  File "<python-input-0>", line 3
    if x := True
         ^^
SyntaxError: invalid syntax

("huh? I thought this version of Python supported the walrus operator...")

So I think adding a new rule is preferable. I opened a PR with suggestion from above: #146305

[gvanrossum]

@pixnixz

For the 1 if 2 else x := 3 I would say it makes sense to parse it as (1 if 2 else x) := 3

It only makes sense because the grammar is defined to disallow assignment expressions after the else in this case. But it really makes no sense at all to parse it the way you show, because to the left of :=, only a simple NAME is allowed.

but I do find it odd that 1 if x := 3 else y is parsed as 1 if x and then we expect else rather than allowing a possible named expression.

I think this can all be fixed by making a few small changes to the grammar, but presumably that requires a PEP. IMO the fix is something like this. Replace this current rule:

expression:
    | disjunction 'if' disjunction 'else' expression 
    | disjunction
    | lambdef

with this:

expression:
    | disjunction 'if' named_disjunction 'else' named_expression 
    | disjunction
    | lambdef
named_disjunction: NAME ':=' disjunction | disjunction !':='

This is still asymmetrical. But we can't allow to change the parsing of (x := 1 if blah else 0) because that already has a meaning.