[PEP 203] Augmented Assignment -- Dermatologist needed

[Eric Jacobs]

Hoping to gather some loonies, Thomas Wouters wrote:

> So, given an instance object `x', the expression
>
>    x += y
>
> tries to call x.__add_ab__(y), which is the `in-place' variant of
> __add__. If __add_ab__ is not present, x.__add__(y) is
> attempted, and finally y.__radd__(x) if __add__ is missing too. 
> There is no `right-hand-side' variant of __add_ab__, because that
> would require for `y' to know how to in-place modify `x', which is
> an unsafe to say the least. The __add_ab__ hook should behave exactly
> like __add__, returning the result of the operation (which could
> be `self') which is to be stored in the variable `x'.

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!

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.

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.

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 will end up limiting users' abilities to mix and match
high-level objects, certainly one of Python's greatest features.

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.

This is one Python Wart we can live without, IMO.