[Python-Dev] PEP 572 semantics: all capabilities of the assignment statement

Guido van Rossum guido at python.org
Thu Jul 5 01:15:35 EDT 2018

Let me be slightly contrarian. :-)

On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico <rosuav at gmail.com> wrote:

> Definitely against augmentation, for several reasons:
> 1) Spelling - should it be :+= or +:= ?

That one's easy. As Nick's (withdrawn) PEP 577 shows it should be simply

> 2) Is the result of the expression the modified value or the original?

Someone (sadly I forget who) showed, convincingly (to me anyways :-) that
it should return whatever the `__iadd__` method returns, or (if there isn't
one) the result of `a = a + b`.

> 3) The use-cases simply aren't as strong.

Here I agree.

> Supporting arbitrary assignment targets (rather than just a simple
> name) could be useful, but can be deferred to a future enhancement
> without impacting the simpler version. I would divide this up into two
> subgroups:
> * Multiple assignment (sequence unpacking)

Tim Peters showed in his response this isn't all that helpful. I also think
we shouldn't open the can of worms about priorities this presents, e.g. is
(a, b := foo()) equivalent to ((a, b) := foo()) or is it like (a, (b :=

> * Assignment to non-simple names eg "x[1] := expr"
> Assigning directly to an item or attribute could in theory be
> immensely valuable. So could multiple assignment, though I suspect to
> a lesser extent. But tell me: Without looking it up, do you know which
> of these constructs support non-simple-name assignment and which
> don't?
> [x[1] for x[1] in seq]
> with ctx() as x[1]:
> except Exception as x[1]:
> from spam import ham as x[1]
> In the enormous majority of cases, every one of these constructs is
> going to be used with a simple name, even though some (I won't say how
> many) do permit you to do what I did here. If Python 3.8 ships with
> assignment expressions restricted to simple names, we can discuss how
> valuable the other forms of assignment target would be, and then
> figure out what to do about the ambiguities - for instance, is "x, y
> := expr" going to be equivalent to "x, (y := expr)" or "(x, y) :=
> expr" ? As it is, we neatly dodge that.

Again, the biggest argument against this is that there just aren't enough
use cases.

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180704/adb5380b/attachment-0001.html>

More information about the Python-Dev mailing list