Augmented Assignement (was: Re: PEP scepticism)

[François Pinard]

[Thomas Wouters]

> On Mon, Jul 02, 2001 at 06:15:10AM +0000, Courageous wrote:

> > x += (1,2,3)
> > ... is not the same as...
> > x=x+(1,2,3)

> > That's just plain wrong.

Sorry to jump in, but I want to join my voice with Courageous'.

> No, that's the *whole intent* of the thing. If x += y was supposed to be
> *exactly* the same as x = x + y, it would have been spelled as 'x = x + y'.
> It isn't, and it's not. It's not supposed to be syntactic sugar for normal
> addition, it's supposed to be syntactic sugar for a method call.

I would be tempted to guess that augmented assignment has been requested so:

   tedious_or_inefficient_denotation = tedious_or_inefficient_denotation + 1

could be rewritten as:

   tedious_or_inefficient_denotation += 1

And that's it.

Of course, operators may also yield __IMPLEMENT__-like methods in objects
wanting to use these operators, where one can do everything s/he wants,
among which implementing new, different and even surprising semantics.

I strongly think that the base Python language should strictly limit itself
to the semantic that "a += b" means "a = a + b" with "a" evaluated once.
and be careful at avoiding any surprising side-effect.  Let's fulfill the
request for augmented assignment, without overshooting it.

Fuzziness in this area does not bring us anything, really.  If you really
want a method to extend an mutable, spell it out as we always did, similar
to list.append(), say, but leave "+" and "+=" alone.

Please, _please_ protect the long-term legibility of Python.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard