[PEP 203] Augmented Assignment -- Dermatologist needed

Huaiyu Zhu hzhu at localhost.localdomain
Mon Aug 14 18:51:07 EDT 2000


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"?

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.

There is no question about the necessity of the first case and its
conceptual consistency.  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.

Huaiyu



More information about the Python-list mailing list