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

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 := foo()))?

* 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