Return value of an assignment statement?

[George Sakkis]

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 ?

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