[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" :-(
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
