[Python-Dev] PEP 572: Assignment Expressions

[Tim Peters]

[Guido, about
     g(items[idx] := idx := f())
]
> Does the PEP currently propose to *allow* that horrible example? I thought
> Tim Peters successfully pleaded to *only* allow a single "NAME := <expr>".

I was "successful" only in that the two of us agreed that would be far
less disruptive, and quite possibly an actual improvement ;-)  But I
only argued for limiting assignment expressions to the form

     identifier ":=" expression

I expected that, given that expressions "naturally nest", chained
targets could still be specified:

    a := b := c:= 5

but since they're all plain names there's no way to tell whether the
bindings occur "left to right" or "right to left" short of staring at
the generated code.  I have no use case for chaining plain-name
targets in assignment expressions, but didn't see a good reason to
torture the implementation to forbid it.  I expected chaining would
just be an unused-in-practice possibility.  Much like, e.g.,

    a in b in c in d

is an unused-in-practice possibility.

And I'll take this opportunity to repeat the key point for me:  I
tried hard, but never found a single case based on staring at real
code where allowing _fancier_ (than "plain name") targets would be a
real improvement.  In every case I thought it _might_ help, it turned
out that it really didn't unless Python _also_ grew an analog to C's
"comma operator" (take only the last result from a sequence of
expressions).  I'll also note that I asked if anyone else had a
real-life example, and got no responses.


There were lots of "real life" cases where plain-name targets allowed
for code improvement, though.


> You don't have to implement this restriction -- we know it's possible to
> implement, and if specifying this alone were to pull enough people from -1
> to +0 there's a lot of hope!

Given my experience with _trying_ to find use cases for fancier
targets, and getting burned every time, I'm on the minus side of the
current PEP, because - best I can tell - all the extra complexity
would create an "attractive nuisance" :-(