[Ivan Pozdeev]
> 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 ;-)
while True:
name, token = _getname(g)
if not name:
break
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]:
or
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").
_______________________________________________
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
