[Python-Dev] PEP 572 semantics: all capabilities of the assignment statement

Chris Angelico rosuav at gmail.com
Thu Jul 5 00:00:08 EDT 2018

On Thu, Jul 5, 2018 at 1:28 PM, Ivan Pozdeev via Python-Dev
<python-dev at python.org> wrote:
> Victor Stinner in "Assignment expression and coding style: the while True
> case" and others have brought to attention
> that the AE as currently written doesn't support all the capabilities of the
> assignment statement, namely:
> * tuple unpacking
> * augmented assignment
> (I titled the letter "all capabilities" 'cuz I may've missed something.)
> Should it?
> Personally, I'm for the unpacking but against augmentation 'cuz it has
> proven incomprehensible as per the 5 Jul 2018 04:22:36 +0300 letter.

Definitely against augmentation, for several reasons:

1) Spelling - should it be :+= or +:= ?
2) Is the result of the expression the modified value or the original?
3) The use-cases simply aren't as strong.

Supporting arbitrary assignment targets (rather than just a simple
name) could be useful, but can be deferred to a future enhancement
without impacting the simpler version. I would divide this up into two

* Multiple assignment (sequence unpacking)
* Assignment to non-simple names eg "x[1] := expr"

Assigning directly to an item or attribute could in theory be
immensely valuable. So could multiple assignment, though I suspect to
a lesser extent. But tell me: Without looking it up, do you know which
of these constructs support non-simple-name assignment and which

[x[1] for x[1] in seq]
with ctx() as x[1]:
except Exception as x[1]:
from spam import ham as x[1]

In the enormous majority of cases, every one of these constructs is
going to be used with a simple name, even though some (I won't say how
many) do permit you to do what I did here. If Python 3.8 ships with
assignment expressions restricted to simple names, we can discuss how
valuable the other forms of assignment target would be, and then
figure out what to do about the ambiguities - for instance, is "x, y
:= expr" going to be equivalent to "x, (y := expr)" or "(x, y) :=
expr" ? As it is, we neatly dodge that.


More information about the Python-Dev mailing list