[Python-Dev] Augmented assignment

[Thomas Wouters]

On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote:

> Thomas Wouters:
> > I'd like some (minor) feedback on the augmented assignment thing I'm working
> > on. I understand Guido is the only one who accepts patches like this, and
> > appreciate that, but I'm hoping someone can at least tell me what I'm doing
> > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> > flap, just tell me so and I'll calm down.

> I don't like this augmented assignment syntax at all! (independent 
> from your particular implementation, which I didn't had a look at).  

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

[ snip quite good summary of the problems with augmented assignment ]

I agree with almost all of the above, except the statement that they do not
add anything. If augmented assignment was only syntactic sugar I would not
have taken Michael's patch and rewritten it; I do not propose auto-increment
operators, and would have a hard time accepting them.

However, augmented assignment *does* add new functionality, because it is a
way to inform the object that is being operated on, that it can do the
operation in-place if it so wants. Instead of having to create a new object,
which might be costly in cpu and/or memory, and doing the operation on that,
the object can choose to do the operation on itself, and return 'self'. If
the object doesn't want to do that, it doesn't have to be any different from
'x = x + 1'. (In fact, augmented assignment should, and does, fall back to
that.)

>
>
> [ snip good example of indexes-with-sideffect ]
>
>

This actually proves the point of augmented assignment. With the syntax

foo[bar()] += 1

You can see that bar() is only called once, so you *know* what index is
being retrieved, and that the new value is stored in the same place. Using

foo[bar()] = foo[bar()] + 1

you can't see by the expression which value is being retrieved and where the
result is stored. You have to remember the rules about operand evaluation to
see that. Yes, 

foo[bar()] += bar()

is indeed more complicated than the above example, but absolutely not more
complicated than the normal-add version that calls bar() three times.

The augmented assignment syntax is actually clearer and more easy to
explain, in my opinion. You can only (accurately) explain

a = a + 1 

as 'add a and 1, and store the result in a'. However,

a += 1

is simply 'add 1 to a'. 

> So I think these +=,-=,*= features are evil.  In the same sense as macro
> preprocessors are evil in 'C' and 'from module import *' is already evil
> in Python.  Add more and more of this stuff and you end up on the dark 
> side of programming.

Well, I like the odd Star Wars film, but I do not believe that the Dark Side
lies opposite the Right Way. The Right Way can't help but be very close to
the Dark Side. You may dislike macro preprocessors in C, but CPython (and
almost all other C code) do use them alot, for functionality which would
otherwise be very hard (or complicated and unreadable) to achieve. The same
goes for 'from module import *' in Python.

The funny thing is that augmented assignment operators and auto in/decrement
operators might be added to C because they were easier to optimize (I dont
think that was the main reason, but I wasn't there ;) but any halfway decent
C compiler doesn't need that explicitness, and can optimize the 'x = x + 1'
expression directly. Python, however, can (currently) not do that, and
*does* need the added syntax to be able to do optimization, even if only to
let the object know it's safe to operate on itself.

Of course, once there are semantics for inplace-operations, it _might_ be
possible to optimize 'x = x + 1' into 'x += 1' ;)

> If augmented assignments will ever become part of Python, I would at least
> like to see a strong recommendation added to the styleguide not to use 
> this feature.

If such a recommendation was added, the change would be useless. Better get
Guido to not add this feature instead, or Python will end up like Perl ;)
I honestly do not care much wether it gets added or not. If Guido decides
not to add it, I'm certain he has very valid rasons for it, and I dont
assume to know as much about Python, the applicability of Python, the
average usage of Python or the Future of Python as he sees it, as him ;)

I-don't-know-any-of-that-in-fact-ly y'rs ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!