[PEP 203] Augmented Assignment -- Dermatologist needed

[Huaiyu Zhu]

On Mon, 14 Aug 2000 21:14:58 -0500, Eric Jacobs <eaj at ricochet.net> wrote:

>> - 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.

[Good example about UserList being mutable yet not in place]

Well, the confusion on UserList is indeed a serious one.  However, where
does the problem lie?   There are three categories of rules in Python:

a. Hard coded in the distribution, not changeable without recompile,
b. Recommanded and obeyed in standard modules, changeable in user modules,
c. Happen to be there, convention, folklore, user defined, etc.

Even the claim that "__add__ never modifies self" is of category b instead
of a, as one can redefine __add__ in a user class any way one wants.

I think the distinction between the first and second case should be of the
category b as well.  The only task remaining is to check all standard module
for compliance when it goes into standard distribution.

>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!

Is this so?  Certainly += is illegal in 1.x.  If you don't use these
operators then there is nothing wrong with UserList.  The retrofitting of
UserList will not invalidate any existing code (I think).  The problem only
occurs if you use new Python distribution but substitute old UserList.py

>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.

The confusion already exists in all method calls.  For example,
a = b.sort()  # Oops, a==None

The way to solve these problems, IMHO, is to set official descriptors for
these three behaviors:

1. in place modification of object
2. binding name to a new  object
3. generate new object without using old name

and encourage clear documentation on all class methods of this nature.

>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.

I would suggest the PEP list a decision tree for using the first and second
case, like

- if it is class object:
  - if there is __add_ab__:
    call it, which may be first (recommended) or second case
  - if it is in standard module:
  - else:
  
- if it is buitin type object;
  - if it is mutable:    use the first case
  - if it is immutable:  use the second case


This style is easier to read than a lot of if-then-else in a plain formated
paragraph.  

Huaiyu