Augmented assignment should never modify the assign target!

[Eric Jacobs]

In article <39B7E746.EE231224 at rsv.ricoh.com>, Bob Alexander
<balexander at rsv.ricoh.com> wrote:
> Sorry if this has already been discussed to death.

If only it were, Bob! I guess it doesn't seem that interesting,
or contraversial ;)

> I was a bit concerned when I saw an early "Augmented Assignment" PEP a
> few weeks ago, and now I'm more concerned since the part of that
> definition that concerns me is still there (in the "What's New in 2.0b1"
> blurb).
> 
> I'm a big fan of augmented assignment. However the statement "if A is a
> mutable object, A may be modified in place" seems like a bad idea. I
> believe that augmented assignment should emulate normal assignment in
> its semantics. That is
> 
> 	target += value
> 
> is always equivalent to
> 
> 	target = target + value
> 
> period!

I agree with you 100%!

> The existing semantics for assignment is that the target object is never
> modified by it (unless one of the operations in "value" has that side
> effect, of course).
> 
> Since the operator + never modifies it operands, += should not either.
> Using augmented assignment could have non-intuitive results in certain
> cases:
> 
> 	a = []
>       b = a
>       a = a + [1]	# this does not modify b
>       a += [1]	# this modifies b!

Absolutely. When I asked this question, the response was basically
"objects can do whatever they want".

That's always been true -- an object in 1.5.2 can modify itself
in its __add__ method even and produce bizarre results. But the
augmented assignment proposal puts this kind of inconsistency
into the interpreter itself. It completely breaks down the
sequence abstraction, and encourages users to define objects with
similar abstraction problems.

> I recommend removing any reference to "in-place" modification as a
> result of augmented assignment. If this recommendation is accepted,
> there would also be no need for the i-prefixed special methods (iadd,
> isub, ...). All semantics could be handled implicitly by the Python
> compiler.

I think the important thing to realize is that in-place modifications
may be nice (and even necessary, sometimes), but that they cannot share
the same syntax as augmented assignment.

The following behavior would be okay:

    tuple += (5,)       # equivalent to tuple = tuple + (5,)
    list += [5]         # equivalent to list = list + [5]

This would also be okay

    tuple += (5,)       # TypeError
    list += [5]         # equivalent to list.extend([5])

(logically consistent, that is. It would be strange not to be able
to do augmented assignment with integers and strings, for instace.
I wouldn't recommend it. But at least it would make sense.)

The "mix 'n match" design style where each object does whatever
is most convenient for it _without_ regard to its abstract
definition is a complete disaster.

(You could say that augmented assignment splits sequence types
into two abstract types: always in-place sequence and never
in-place sequence. But mismatching those two incompatible types
may not even throw an exception -- it might simply give strange
results. This is another thing the PEP fails to address.)

> IMO, removing the in-place stuff would prevent unnecessary and misguided
> complication of the language.

Absolutely. In-place modification should be considered
completely indepenendently from augmented assignment.

Python may have only been a 95% language, but I have a
feeling it's about to drop a letter grade :(