while ((name, token) := _getname(g)) and name:

Using a trick sucks.  Not relying on a trick is ugly and inefficient:

">

(original) (raw)

\[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").