On Feb 21, 7:21 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote: > Steve Holden wrote: > > Jeff Schwab wrote: > >> [EMAIL PROTECTED] wrote: > > [...] > >>> Now there's no reason to feel nervous about this. All you have to > >>> remember is that Python never copy anything unless explicitely asked > >>> for. > > >> It's not that simple. After a statement like: > > >> a = b > > >> Whether a and b denote the same object depends on what kind of object > >> b represented in the first place. > > > Surely this is exactly wrong. Is there a single example you can think of > > where > > > a = b > > a += b (my bad) > > > assert a is b, "Oops!" > > > would raise and exception? Perhaps you meant to use an augmented > > assignment operation? > > Why, yes I did! Sorry about that.
It seems less surprising when you keep in mind that "+=" (and friends) can be syntax sugar for calling a method on the right hand side object: a += b <=> a.__iadd__(b). It's up to the class of 'a' to do whatever within this method (whether it's a good idea to do anything else other than modify 'self' in place is another thing). Would you be able to say anything about a.foo(b) without knowing what 'a' is ? The only difference is that for types that don't implement an augmented operator, "a `op`= b" translates to "a = a `op` b" for a binary operator `op`. There's no formal notion of mutable and immutable objects with respect to these operators; any class that doesn't implement them is "immutable" as far as augmented assignment goes (of course it may be mutated in other ways, e.g. by fiddling with a.__dict__ directly). On the other hand, "a = b" does always the same thing; unlike C++, '=' is not an operator and therefore it cannot be overriden by the class of 'a'. George -- http://mail.python.org/mailman/listinfo/python-list
