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

[Guido van Rossum]

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>