[Chris Angelico <ros...@gmail.com>] > I don't see much value in restricting the assignment target to names > only, but if that's what it takes, it can be restricted, at least > initially.
I believe this point was made most clearly before by Terry Reedy, but it bears repeating :-) This is from the PEP's motivation: """ Naming the result of an expression is an important part of programming, allowing a descriptive name to be used in place of a longer expression, and permitting reuse. """ As "head arguments" go, that's a good one! But restricting assignment expressions to identifier ":=" expression satisfies it. If what's of value is to name the result of an expression, that single case handles that and _only_ that. In a sense, it's "the simplest thing that could possibly work", and that's generally a good thing to aim for. Python assignment _statements_ are way more complex than that. Besides just giving names to expression results, they can also implicitly invoke arbitrarily complex __setitem__ and __setattr__ methods on targets, rely on all sorts of side effects across chained assignments, and support funky syntax for magically iterating over an expression's iterable result. While that can all be useful _in_ an assignment statement, the PEP's motivation doesn't say a word about why any of _that_ would also be useful buried inside an assignment expression. There doesn't appear to be a good "head argument" for why, besides "why not?". That's not enough. I think it's no coincidence that every example of an _intended_ use is of the simple identifier ":=" expression form. There are no examples of fancier targets in the PEP, and - more importantly - also none I saw in the hundreds of mailing-list messages since this started. Except for a few of mine, where I tried to demonstrate why _trying_ fancier targets in examples derived from real code made the original "loop and a half" code _worse_ And where other people were illustrating how incomprehensibly code _could_ be written (which isn't a real interest of mine). Short course: e.g., while a general assignment expression can "unpack" an iterable expression result, giving names to its elements, there's no clean way to _use_ the names bound by the unpacking _in_ the "if" or "while" tests. That's fine for `for` loops (only the _body_ of the loop needs the names), but in conditional constructs you typically want to use the names _in_ the condition being tested. if ((a, b, c) := func_returning_triple()) and b > 0: process(a+b, b+c, a+c) seems to be as good as it gets, but inherently relies on "a trick": that a 3-tuple is always truthy, regardless of content. OTOH, if ((a, b, c) := func_returning_triple())[1] > 0: doesn't rely on a trick, but can't use the name `b` in the test(!). if [((a, b, c) := func_returning_triple()), b > 0][-1]:: manages to avoid "a trick", and to use the natural `b > 0`, but is ... strained ;-) So, to my eyes, this is a clear improvement over all of those: a, b, c = func_returning_triple() if b > 0: process(a+b, b+c, a+c) Of course I could be cherry-picking a bad example there, but that's not the intent: I'm still waiting for anyone to post an example where a "fancy" assignment-expression target would actually make code clearer. I haven't found one. There are lots of examples when the target is a plain single name. Why the stark difference? I don't need deep theoretical reasons to see that there _is_ one, or to conclude that - in the absence of compelling use cases - complex assignment-expression targets are probably a Poor Idea. _______________________________________________ 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