Compound Assignment Operators ( +=, *=, etc...)

[Andrew McDowell]

First off, I'd like to apologize for the Compound Assignment Operator vs.
Compound Assignment Statement confusion...
I'll get the hang of this some day <grin>


Tim Peters wrote:

>  Seriously, the problem at the start was simply one of
> non-obviousness.  For example, if x and y are lists, does
>
>     z = x
>     x += y
>     print z
>
> mean
>
>     x = x + y   # x is now bound to an entirely different object
>     # and the old x is printed
>
> or
>
>    x.extend(y)   # x is still the same object, but mutated
>    # and the new x is printed
>
> ?  The resulting *values* compare equal either way, but there are
> differences in efficiency and effects on object identity.
>

I don't see where the "non-obviousness" comes into play...
(maybe that's why it's not obvious <wink>)

Why would you confuse x += y (which would seem to imply the former) to mean
x.extend(y) ?   It _is_ and assignment statement after all..


>
> There were more important questions to resolve first, and the lack of
> augmented assignments hasn't caused enough people enough pain to force a
> resolution of these questions.

Not to touch on a sore topic, but hop over to comp.lang.perl and check out the
(rather long and heated) comparison of perl and python.
The lack of these statements is causing quite a bit of a stir.


>  Nevertheless, in good Pythonic fashion,
> Guido's favored resolution is to say it's up to the object:  whatever type x
> may happen to have, it's up to x.__addeq__(y) to decide what "+=" (& so on)
> means.
>

Why addeq??  Why not just add?

>
> 5) Not having it was good enough for my grandfather, and what makes you
> think you're better than him <wink>?
>

Because Python wasn't around then! <wink>