[PEP 203] Augmented Assignment -- Dermatologist needed

[Eric Jacobs]

In article <slrn8pgu75.u2.hzhu at rocket.knowledgetrack.com>,
hzhu at localhost.localdomain (Huaiyu Zhu) wrote:
> On Mon, 14 Aug 2000 15:23:01 EDT, Eric Jacobs <eaj at ricochet.net> wrote:
>>
>>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 points to an interesting conceptual question: Are immutable objects
> capable of be modified "in place"?

No. The "in place" part really isn't meaningful; the crux of the issue
is whether the object is modified, or a new copy made. Since immutable
objects cannot, by definition, be modified, a new copy is always made.

> According to the PEP, the statement
> 
> x += 3
> 
> would do either
> 
> - If x is mutable, modify the object referenced by x.  Other names
> sharing
>   the object would still point to the same (changed) object.  If (y is
>   x) was true, it remains true.
> 
> - If x is immutable, generate a new object and let x refer the new
> object.
>   Other names sharing the object would still point to the same
>   (unchanged) object.  If (y is x) is true, it is now false.

Not always true! This is _exactly_ the kind of confusion that I'm afraid
this PEP will create.

>>> from UserList import UserList
>>> x = UserList([1,2,3])
>>> x[0] = 0 # mutable
>>> y = x
>>> x += [4]
>>> x
[0, 2, 3, 4]
>>> y
[0, 2, 3]

UserList is definitely mutable, however it will not modify itself as
part of an augmented assignment statement. Of course, UserList.py
could be updated to include to include the __add_ab__, etc. methods.
However, I don't think you want to say that UserList.py from the
1.x library is _illegal Python_ in 2.0... a lot of classes from
1.x would be illegal, then!

s/is mutable/wants to/
s/is immutable/wants to/
would more accurately describe the situation created by the proposal.

Even if it did work the way you described, it would require knowledge
of whether or not the object is mutable to be able to use augmented
assignment correctly. This is silly, because the user may not even be
trying to accomplish anything having to do with modifying the object.
A mutable object ought to be able to be used the same way as an
immutable object. Intuitively, a mutable sequence is a subclass of 
an immutable sequence.

> There is no question about the necessity of the first case and its
> conceptual consistency.

I agree in that I like the concept, but calling it an augmented
assignment is out of place. Where is the concept of "assignment"
in list.extend? There is none. There is nothing in list.extend that
corresponds to the Python notion of assignment; i.e., binding a
reference to a name.

"Augmented assignment" makes more sense in the second case, because
we're assigning a new object:

> The second case is more like a shorthand way of
> saying
> 
> x = x + 3
> 
> which is still handy, but would not really fit the term "in place". (Of
> course it is more than just shorthand, like x[0] += 3 only invokes
> __getitem__ once.)
> 
> Do we want the second case?  I think I do.  But the docs should be more
> clear about this not being "in place".  Put it another way, the "in
> place" nature of the second case is realized in the name, not the
> object.

I agree that should be made clear. This is why I think that the PEP is
just plain trying to cover way too much ground. Being able to avoid
the extra typing and lookups is definitely a worthwhile feature, IMO.
It just needs to be kept clear and distinct from operations like
list.extend, which are doing something totally different. The most
important issue is not whether we want the first vs. second case,
but how the user is to know which case applies when they write the
augmented assignment statement.

> 
> Huaiyu