George Sakkis wrote: > 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 ?
Yes: I would know that it didn't rebind a. > 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). Thanks for explaining that. > 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'. "Not an operator?" Then what is it? -- http://mail.python.org/mailman/listinfo/python-list
