A Summary: Expression-Assignments. (Very Long)

[Fredrik Lundh]

Phil Hunt wrote:
> I'd like to see += in Python.

for everyone's amusement, I've attached a piece from
the second ever message posted to the mailing list that
later turned into comp.lang.python.  I'm not sure, but I
suspect the fact that assignment operators still hasn't
made it into the language might mean something...

</F>

from: Guido van Rossum
to: python-list at cwi.nl
date: Sat, 23 Nov 91 16:35:12 +0100

/.../

>How about providing assignment operators?  Some time one has to
>build a thing piece-meal and this sort of operators are very
>handy.  The semantics are clear:
>
>  <var> <op>= <expr>  === <var> = <var> <op> <expr>
>
>Example:
> a = 'ba '
> a *= 2                  # a = 'ba ba'
> a += 'black sheep'      # a = 'ba ba black sheep'

Agreed.  Now that the parser can actually recognize two-character
operators, adding these wouldn't be so hard (except that the grammar
tables will grow again :-( ).

>I would also like the capability of overloading standard operators
>for predefined and user defined classes.  Thus instead of
>       result.append(b)
>I should be able to say
> result += b
>or better still,
> result += [a,b,c]

The latter should automatically work if we let x += y be syntactic
sugar for x = x+y.  Note that result = result + [x] has a different
meaning than result.append(x), although in many cases it doesn't
matter: result.append(x) modifies the existing object that result is
bound to, while result = result+[x] creates a new list (the
concatenation of result and [x]) and binds result to it, forgetting
the object to which result was bound previously.  If there was another
reference to that object, e.g., through an assignment "z = result"
earlier on, the value of z is unchanged by the second form, but
modified by the first form.  Confusing?  Yes, but this is a lot better
than allowing arbitrary pointers!

/.../

--Guido van Rossum, CWI, Amsterdam 
"All right, it's a fair cop, but society is to blame."