[SciPy-dev] In-place operators and casting

[Fernando Perez]

Paul Barrett wrote:

> As you noted, a += b is really just a short hand for a = a + b, so upcasting
> makes sense to me.

I'm afraid it's a bit more subtle than that in python, due to the fundamental 
distinction between mutable and immutable objects.  Hopefully this example 
will clarify things:

In [1]: objs = [['hi'],9]

In [2]: for o in objs:
    ...:     id1 = id(o)
    ...:     o += o
    ...:     id2 = id(o)
    ...:     if id1==id2:
    ...:         print 'Object <%s> was modified in-place' % o
    ...:     else:
    ...:         print 'Object <%s> was replaced by a new one' % o
    ...:
Object <['hi', 'hi']> was modified in-place
Object <18> was replaced by a new one

For a list, a+=a is NOT shorthand for a = a+a, because the operation keeps the 
  same python object.  For integers, on the other hand, it is: a += a under 
the hood does the equivalent of 'tmp = a+a;a = tmp', creating a new object 
which is rebound to the name 'a'.

As far as I understand (please correct me if I'm wrong), the basic python 
behavior for builtin types is, for <x> any operator with an in-place version:

a <x>= expr  <==> a = a <x> expr  iff a is an immutable object.

If a is mutable, the operation may be implemented truly in-place, without 
object rebindings and by shrinking/growing/reallocating the object as needed.

If we are to follow the default semantics of the language for in-place 
operations, then I suppose that we shouldn't allow object ID changes, and 
raise exceptions in cases where an object re-allocation would be required to 
satisfy the in-place operation.

As convenient as I find the in-place operators, I tend to think that due to 
the mutable/immutable subtleties of python, they have too much gotcha 
potential in the language.  I almost wonder if Python wouldn't be better off 
without them...

Cheers,

f