[SciPy-dev] In-place operators and casting
Fernando.Perez at colorado.edu
Thu Nov 24 12:42:36 CST 2005
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 : objs = [['hi'],9]
In : for o in objs:
...: id1 = id(o)
...: o += o
...: id2 = id(o)
...: if id1==id2:
...: print 'Object <%s> was modified in-place' % o
...: 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
More information about the Scipy-dev