Document better assignment expression parentheses requirements

[lysnikolaou]

Feature or enhancement

Proposal:

Should we maybe thinks about allowing unparenthesized top-level assignment expressions. It came up on ipython/ipython#14214 that people would like to have something like that, especially in REPLs, in order to be able to assign a value to a variable and have it be displayed afterwards. I played around with the parser a bit and the change to allow this is very straight-forward.

We could also discuss adding it behind a flag or only enable it on the REPL.

Behavior on main:

❯ ./python.exe
Python 3.13.0a1+ (heads/main:baeb7718f8, Nov 10 2023, 12:05:38) [Clang 15.0.0 (clang-1500.0.40.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a := 3
  File "<stdin>", line 1
    a := 3
      ^^
SyntaxError: invalid syntax

New behavior:

❯ ./python.exe
Python 3.13.0a1+ (heads/main-dirty:baeb7718f8, Nov 10 2023, 12:20:20) [Clang 15.0.0 (clang-1500.0.40.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a := 3
3

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-111944: Add assignment expression parentheses requirements #111977
• [3.12] gh-111944: Add assignment expression parentheses requirements (GH-111977) #112010
• [3.11] gh-111944: Add assignment expression parentheses requirements (GH-111977) #112011

[lysnikolaou]

@terryjreedy I don't think the type-bug label applies here. The current behavior is correct according to the specification in PEP 572.

[terryjreedy]

Top level assignment expressions work when parenthesized.

>>> (a := 3)
3
>>> a
3

According to the expression doc
this should not be needed. The discrepancy would usually be seen as a bug.

According to the PEP, the behavior is intended, with the parenthesized form discouraged. See the first example under exceptional cases. So it seems that the doc should be fixed unless it is intended that the discouraged form not be documented. But I believe this would be unusual.

To support a feature addition, argue against the PEP's prohibition rationale.

@gvanrossum

[terryjreedy]

Bug is for the doc not including 'top level code' in the list of places where parentheses are required. This list is characterized as all-inclusive by saying 'not needed' everywhere else.

[lysnikolaou]

I'm sorry, I might not have made myself clear.

I understand all that. I agree that the doc should be improved to include that top-level walruses need parentheses. But that should probably be a different issue. What I would like to do with this one, is start a discussion on whether we should lift that restriction.

The PEP says:

Unparenthesized assignment expressions are prohibited at the top level of an expression statement. [...] This rule is included to simplify the choice for the user between an assignment statement and an assignment expression – there is no syntactic position where both are valid.

I agree with the concept of "There should be one way to do it", but I would think that, in the context of a REPL, assignment statements and assignment expressions do two slightly different things. And I'm asking whether others agree so that this can be lifted, since it's also a very easy change to implement on the parser side.

[gvanrossum]

I am not in favor of lifting the restriction. I don’t want there to be two top level forms of assignment.

[lysnikolaou]

I am not in favor of lifting the restriction. I don’t want there to be two top level forms of assignment.

What if it could only be enabled with an ast.PyCF_ALLOW_TOP_LEVEL_WALRUS kind of flag in ast.parse/compile in single mode? Would that make a difference?

I'm asking because I generally agree with the sentiment. It's only in the context of a REPL, where I think this could be a slight improvement.

[gvanrossum]

That would only confuse users — what’s valid in one context wouldn’t be valid in another context.