[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