One last shot at the Augmented Assignment PEP

[Huaiyu Zhu]

I'm going to further make the case for two augmented assignment operators
        +=	+!
I have three points to make.

Point 1: Suppose expr is an expression, which is not necessarily a name.
There are three very distinct cases people may call augmented assigment:

case 1. Evaluate twice, rebind name
	a[expr] = a[expr] + 1

case 2. Evaluate once, rebind name
	a[expr] += 1    # tmp = expr; a[tmp] = a[tmp] + 1
	                # tmp = expr; a.__setitem__(a.__getitem__(tmp)+1)

case 3. Evaluate once, modify in place
	a[expr] +! 1    # tmp = expr; a[tmp].__in_place_add_by__(1)

Clearly, case 2 and 3 deserve to have their syntactic sugar, which is what
the current PEP provides.  It's simply wrong to say that they are the same
as case 1.  Hence the necessity of the extension.


Point 2: But the current PEP uses the same syntax += to cover both case 2
and 3, depending on

- For builtin type, is it mutable?
- For class objects, does it have __iadd__?

Is this sufficient?  I'd imagine that even for the same object, different
choices between case 2 and 3 often make sense in different situations.
Should you ask the objects whether they like to be mutated in place, or
should you ask the programmer to specify her intention?  I'm not convinced
that mutable objects always want to be mutated.

But I'm not going to argue here that one single syntax covering two cases is
really deficient.  But suppose it is, as many here seem to agree, can we
afford to leave this to the future?  No way.  Once += is used for both case
2 and 3, it would be impossible to change its meaning without breaking code.


Point 3: But what about polymorphism?  Maybe the user really doesn't care
about the distinction between augmentation and assignment.  Maybe the
objects are designed to be automagically correct.  Do we want to force the
users to make a choice, thereby limiting the applicability of programs?

Well, the relation between +! and += could be treated the same way as that
between str and repr: __str__ is intended for human readable printing while
__repr__ for machine readable printing, but if __str__ is not defined, str
would just use __repr__ any way.

So I would suggest two magic methods with defaults (a is only evaluated once)

a += 1  # a.__add_and_rebind__(1) if defined
        # a = a + 1 otherwise

a +! 1  # a.__inplace_add__(1) if defined
        # a += 1 otherwise.

For immutable objects, +! would then be the same as +=.  But for others they
are often different.  Thus we can have both user control and polymorphism.

like-eating-the-cake-and-having-it-too-ly y'rs

Huaiyu


On Fri, 15 Sep 2000 12:38:55 -0700, Bob Alexander <balexander at rsv.ricoh.com>
wrote: 
>My collected responses to several posts on this topic:

[snip good summary]