[Python-Dev] PEP 572 semantics: all capabilities of the assignment statement
tim.peters at gmail.com
Thu Jul 5 00:06:37 EDT 2018
> 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.)
> Assignment statements (and `for` headers) also allow arbitrarily complex
applications of subscripting and attribute references. Like
for a[b].cde[f, g(h, i, j)].k in range(10):
> Should it?
Already been considered and rejected, so no.
Victor already showed why, but didn't quite realize it ;-)
name, token = _getname(g)
if not name:
Allowing to unpack the two names in an AE wouldn't really help, because
there's still no satisfying way then to _reference_ just the `name` part in
the `while` test:
while ((name, token) := _getname(g)) ... and now what??
You could use "a trick", relying on that a 2-tuple is always truthy:
while ((name, token) := _getname(g)) and name:
Using a trick sucks. Not relying on a trick is ugly and inefficient:
while [((name, token) := _getname(g)), name][-1]:
while [((name, token) := _getname(g)), name].pop():
where the thing to be tested is the second list element (e.g., `name ==
"not done yet"`).
So no plausible use cases were ever presented, and the idea was dropped.
If we _also_ added something akin to C's comma expressions (evaluate a
sequence of expressions and throw away all the results except for the
last), then a reasonable spelling akin to the last one above could be used,
but without the strained cruft to muck with a result list (or tuple).
At which point my rule for AE would likely never trigger ("if it's not
obviously better, don't use it").
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev