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

[Tim Peters]

[courtesy cc of this posting mailed to cited author]

[Drew McDowell]
> I looked in the FAQ and couldn't find anything on the Compound
> Assignment Operators.  (+=, *=, -=, etc..)  Why doesn't Python
> support them?

Look in the ToDo list, or search DejaNews very hard <wink>.

> Is there a easy way to add them?

Nope.

[switching to Tom Christiansen]
> Well, to start with, Python does not even *have* an assignment
> operator.  Nope, not one.  Assignment is a statement, not an
> operator.
> [followed by the familiar confusions owing to assignment operators
>  in C]

That's indeed why Python doesn't have assignment operators.  Drew was really
asking why Python doesn't have Compound Assignment Statements (he'll get
back to why it doesn't have assignment operators  ...), so:

> ...
> As for why you can't write the statement (note: not the expression)
>
>     x["every"]["good"]["boy"]["does"]["fine"] =  (
> 	x["every"]["good"]["boy"]["does"]["fine"] + 1 )
>
> as
>
>     x["every"]["good"]["boy"]["does"]["fine"] += 1
>
> The basic reason seems to be that there are some people who believe
> that this kind of thing is cruel and unusual punishment levied upon
> the poor Pascal(ish) programmers purely for sake of brevity.

THere are, but Guido isn't one of them.  He's on record as liking augmented
assignments well enough that he'd put them in someday if more than 6 people
cared <wink>.  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.

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.  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.

> Common arguments in support of such ops include:
>
>     1) This requires care to avoid mis-duplication:
> 	...
>     2) Side effects must be duplicated:
>     ...
>     3) It's too long to type.
>     4) Needless redundancy obscures the real meaning.

5) Efficiency.

> Whereas common rebuttals include:
>
>     1) Toss /bin/ed and get yourself a real editor.
>     2) Don't use side-effects, you wicked creature, you!
>     3) It's more efficient to keep a tmpobj anyway.
>     4) Redundancy can clarify through redundancy.

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

> ...
> But the best reason is probably the one another poster already
> supplied: because Guido didn't like them.

Not so in this case (++x and x++ are a different matter).  Supply & demand,
and need vs desire, get closer.

> An interesting study would be to check the extent to which he
> also forbids such constructs in his own C code. :-)

Python's implementation begins with:

#define colon {
#define dedent }
#define spaces(E) (E)
#define rspace )
#define newline ;

if spaces(sVersion == 0) colon
    printf("internal error") newline
    exit(1) newline
    dedent

if-perl-really-believed-in-freedom-it-would-have-a-
    character-level-preprocessor<wink>-ly y'rs  - tim