Return value of an assignment statement?

[Jeff Schwab]

George Sakkis wrote:
> On Feb 21, 7:21 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
>> Steve Holden wrote:
>>> Jeff Schwab wrote:
>>>> bruno.desthuilli... at gmail.com 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?