[PEP 203] Augmented Assignment -- Dermatologist needed

[Thomas Wouters]

On Mon, Aug 14, 2000 at 03:23:01PM -0400, Eric Jacobs wrote:

> The phrases "behave exactly like __add__" and "which could be `self'"
> are contradictory. Since __add__ never self-modifies, and __add_ab__
> may, their behavior is not exactly alike! This is an important
> distinction!

Indeed. I've adjusted the text to point this out. (just commited, HTML
version takes a bit of time.) It now says 'should behave similar to ...',
which together with the rest of the PEP should be sufficient explanation. I
hope :) The PEP isn't intended as a tutorial on the use of augmented
assignment.

> Suppose x is a 5-element sequence. After executing

>     y = x
>     x = x + x[:3]

> len(y) == 5. But after instead executing the seemingly equivalent:

>     y = x
>     x += x[:3]

> len(y) is unknown! Even though those statements use only operators
> that are defined for sequence objects, the result still depends on
> the specific type that the sequence happens to be. For tuples,
> strings, and UserLists, len(y) will come out to be 5; but for lists,
> len(y) will be 8.

Yes. This is already the case. Consider

y = x
do_something(x)

What did 'do_something' do ? Is 'x' mutable ? Did it alter 'x' ? Did 'y'
alter along with 'x' ? What if this is the global namespace, and
'do_something' could modify both 'y' and 'x' separately !?

> This is a major breakdown in the abstract objects layer. Instead
> of being able to think of an object as a "sequence object", users
> will be forced to make assumptions about the object's behavior
> regarding in-place modification.

As they already are regarding behaviour in the case of normal binary
operators.

> So someone might write a function that takes a sequence object as
> an argument (i.e., it does not use any methods that are specific
> to lists, or any other specific type), but test it only using
> lists. If someone comes along and passes a tuple, or a custom
> sequence type, there's a possibility that the function will not
> work right. Worse yet, it may not even raise an exception; it
> may just produce bogus results!

This posibility is not specific to augmented assignment. It already applies,
though I have to admit I've never seen it happen.

> This will end up limiting users' abilities to mix and match
> high-level objects, certainly one of Python's greatest features.

I agree that the abstraction is one of Python's greatest features, but I
doubt it will be limited by augmented assignment. If you do not know what
augmented assignment is going to do to your object, *don't use it*. There
are no plans to remove normal binary operators, yet. <wink>

> By trying to pour in augmented assignment, mutation operators
> (to replace e.g. list.extend), and in-place modification all at
> once, PEP 203 succeeds only in making Python's abstract objects
> layer into a confused soup.

It is either this, or ending up with augmented assignment that is *only*
syntactic sugar for normal assignment. And the decision has to be made now,
before adding it. After adding it, it cannot be changed (except perhaps by
the mythical Py3k.) Making augmented assignment not fall back to the normal
binary operations is not an option, in my opinion, since it would make
augmented assignment practically useless if you do not know what type you
are talking about.

Making _sane_ use of augmented assignment and the hooks behind it is up to
the programmers. I do not see more room for confusion than with, say, normal
binary operands, which *could* make Python classes do the weirdest things.
I've never seen a piece of Python code that did not choose the most
'obvious' use for those operators, so why would people do unexpected things
with inplace operators ?

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!