[Python-Dev] Augmented assignment

[Gordon McMillan]

Peter Funk wrote:

> Augmented assignments are unPythonic because they don't add any
> new functionality to the language.  

Most changes to Python are nothing but syntactic sugar.

In concept, I'm +0.9 on simple "name += val".

I'm -0.9 on "expr += val" if the behavior requires an 
understanding of Python internals, and +0 otherwise (since I 
avoid "expr = expr + val" if possible).

Thomas's statement that the complexity is largely due to 
problems of thread safety is eminently believable, and I doubt 
that the syntactic sugar (which is at least somewhat 
desirable) is worth the price. 

> ....  Many of these features were born in the
> 70s of the last century:  At that time optimizing was very
> important and compilers were relatively dumb.  This applies in no
> way to the situation we have today with Python.

Actually, Python's compiler is very dumb, and optimization is 
still important. So where I would use "expr" 3 times in 3 lines 
in C / C++ and *expect* the compiler to optimize it into one 
evaluation, I have to remind myself to use an extra line and 
compute it once in Python myself. One might argue that that's 
unPythonic, because it inhibits the direct expression of the 
idea. One might, but I won't.
 
> What remains is, that augmented assignments are only a short cut
> notation, which introduces more variability to express the same
> algorithms and so they hurt readability.  

It definitely *improves* the readability of incrementing very-long-
expression. Just not to the point of readability ;-).

> ...  It also introduces many more
> possibilities to make subtle mistakes,

and eliminates othes, such as typos...

> since it is not obvious
> (at least to No-C-programmers) when and how often the index
> expression will be valuated.  Look at the following example:
> 
>         class Bar:
>      def __init__(self):
>          self.val = 0
>      def __call__(self):
>          self.val = self.val + 1
>   return self.val
>  bar = Bar()
>  foo = range(4)
> and than
>  foo[bar()] = foo[bar()] + bar()
>  print foo
> versus
>  foo[bar()] += bar()
>  print foo

To understand the first requires a sufficiently deep 
understanding of how Python works that I doubt the 2nd is 
really much worse. They're both the other side of horrid.
 
I don't care very much myself, but none of these arguments 
are without strong counters (which we've all read many times 
on c.l.py). The only real basis, I think, is whether the changes 
complexify things too much.

- Gordon