Augmented Assignement (was: Re: PEP scepticism)

[Steve Holden]

"François Pinard" <pinard at iro.umontreal.ca> wrote in ...
> [Thomas Wouters]
>
[ ... ]
>
> 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.
>
Nope. It was included to allow useful abbreviation of method calls,
specifically allowing in-place update of mutable objects where the object
implementation decided this was suitable.

> 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.
>
Too late. Since augmented assignment has been around in its present form for
almost a year now (IIRC) to change the definition at this stage would break
existing code, and that just isn't acceptable. I felt more or less the way
you do when this change was made, but there really isn't any point going
back to try and fight this battle again. You have to live with Python the
way it is (and nobody id going to *force* you to use augmented assignments).

> 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.
>
Sorry. Move on!

regards
 Steve

--
http://www.holdenweb.com/