One last shot at the Augmented Assignment PEP

[Bob Alexander]

"Alex Martelli" <aleaxit at yahoo.com> wrote"

> Consider the sequence of statements:
>     a = copy(x)
>     b = copy(x)
>     a = a + y
>     b += y
>     assert a==b
> 
> This seems a pretty good operational definition to me, for the
> semantic equivalence of the 3rd and 4th statements.  "When
> operating on variables bound to identical copies of some object,
> they leave each variable bound to an object such that the two
> variables compare-equal".

Yes, when no other bindings share those same values, they are
indistinguishable. But in Python programs, values are often bound to
more than one variable (or "pseudovariable", like a list element). If
you change your example a bit:

     a = aa = copy(x)
     b = bb = copy(x)
     a = a + y
     b += y
     assert a==b	# succeeds
     assert aa==bb	# fails

it seems wrong to me that there is a non-obvious side effect that
modifies bb. (You might have had to look twice to notice that.) And it
only applies to the second form, even though their appearance could fool
one into thinking they do the same thing. aa was untouched, an one would
expect of concatenation and assignment (or rebinding, or whatever you
like to call it).

> ... += and its ilk would be mere syntactic sugar of no big real interest.

I agree that += would be "mere" syntactic sugar, but I disagree that it
is of no big interest. It can reduce the labor of writing and the
clarity of reading, and that is of very real interest to me. Oddly,
syntactic sugar can make programs actually *lose* weight!

I don't think it is important or desirable to try to make augmented
assignment "more interesting" by introducing these additional semantics
that don't fit the expectation of assignment.

Is it really too late to change this? 2.0 isn't final yet.

Bob