One last shot at the Augmented Assignment PEP

[Huaiyu Zhu]

On Wed, 13 Sep 2000 11:15:42 -0700, Bob Alexander <balexander at rsv.ricoh.com>
wrote: 
>Seems as though most members of this list are pretty happy with the
>recent Augmented Assignment PEP definition.

Well, I'm one of those who are pretty happy with _having_ this, but not
quite happy with all its details.  But the the complaint is in the other
direction.

>As a proponent of *true* augmented assignment, though, I suggest we
>rename that new feature in Python to something more appropriate to the
>definition. Like "sometimes-augmented sometimes-assignment". Or "totally
>new operators having little to do with assignment".

How about calling them "augmentation operators"?  Their main appeal is that
they actually _changes the object in place_.  They look like assignment in
other languages, but not at all like the reference-based name-binding
assignment of python.

[snip example of in place operation]

>And then there's
>
>    tup = ()
>    lst = []
>    tup += (33)
>    lst += [33]
>

You meant this:

>>> a = b = []
>>> a += [33]; b
[33]
>>> a = b = ()
>>> a += (33,); b
()

This to me is the _only_ problem (but a really big one) with these
operators.  They should be undefined on immutable types!  But that would
upset people using a+=b has a shorthand for a=a+b, because they do want

>>> a = b = 0 
>>> a += 33; b
0
>>> a = b = 0
>>> a = a+33; b
0

So these are now "augmentation-for-mutable-object, assignment-for-
immutable-object" operators.  I don't think this is more difficult to
explain than the distinction between tuples and lists itself.

Maybe the true solution is for each immutable builtin type to have a mutable
class correspondent.  Then users can choose the behavior that makes most
sense in the applications.

Huaiyu