Python 2.0b1 is released!

Remco Gerlich scarblac-spamtrap at
Thu Sep 7 10:11:56 CEST 2000

John W. Baxter wrote in comp.lang.python:
> In article <Pine.LNX.4.21.0009061312290.24593-100000 at>, 
> phd at wrote:
> >    Do you prefer
> > dict["key"].attr = dict["key"].attr + 12
> >    instead of
> > dict["key"].attr += 12
> >    ?
> > 
> >    The second is cleaner and faster, right?
> > 
> Many people think the augmented assignment form is cleaner.  (I don't 
> happen to be one of them...I'd probably do the above with += in throw 
> away code but not in a real project.

But *why* not?

Not repeating the expression surely makes it more readable. And splitting
it up into two commands make it two lines (more reading), gives a variable
in your namespace (so add a del, or keep readers of your code wondering
if it's used later on), is slower, and there's this thing called augmented
assignment which does exactly the same thing.

I think += is great, have been missing it a long time.

> It may or may not be (that is, the C equivalent, which means 
> something other than a dictionary) hasn't been faster in decent C 
> implementations in many years.  It *was* faster on a particular 
> processor [PDP-11] (and probably others) with early C compiler 
> implementations.  [Check the generated code...these days the two forms 
> tend to produce the same code.]

But x=x+y and x+=y do different things in Python (if x is mutable), so you
can't really compare it to the C equivalent I think.

> And, I suspect, this sort of thing doesn't change (today's challenge:  
> come up with a problem statement in which the following makes sense ;-)):
> dict["key"] = dict.get("key", 244) + 12

Hmm, that's right.

Remco Gerlich,  scarblac at
"This gubblick contains many nonsklarkish English flutzpahs, but the
 overall pluggandisp can be glorked from context"  (David Moser)

More information about the Python-list mailing list