[Python-Dev] PEP 572 semantics: all capabilities of the assignment statement (original) (raw)

Tim Peters tim.peters at gmail.com
Thu Jul 5 00:06:37 EDT 2018

[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"). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180704/accaba9e/attachment.html>

More information about the Python-Dev mailing list