One last shot at the Augmented Assignment PEP

[Remco Gerlich]

Steve Holden wrote in comp.lang.python:
> Bob Alexander wrote:
> > Seems as though most members of this list are pretty happy with the
> > recent Augmented Assignment PEP definition.
> 
> Well in that case count me as a member of the minority :-(

And me as one of the majority (if indeed it is one).

> There seems to be a more autocratic feel to recent changes, but
> then the BDFL has earned the right to go his own way, not matter
> how ill-advised we lesser mortals may feel the path to be.

The recent changes have all been asked for and argued about for years.
I feel it's hardly autocratic.

> > Note that in
> > 
> >     a = []
> >     a += [33]
> > 
> > neither "+" (list concatenation) nor "=" (assignment) are performed
> > <wink>*.

That's why it says "+=" and not "+" or "=". It's a new statement. It's
pragmatic. Python has always been more pragmatic than extremely clean,
and that's what's cool about it.

> > Furthermore, in
> > 
> >     a = []
> >     b = a
> >     a += [33]
> > 
> > b changes. Neither "+" (list concatenation) nor "=" (assignment), would
> > affect b at all.

If they did, we wouldn't need +=.
 
> This is the show-stopper for me.  There's been enough discussion on this
> list about these new semantics to make me hesitate to enter the fray at
> this late stage, but frankly it seems to be asking for trouble to
> implement an augmented assignment operator where the semantics of
> 
> 	x <op>= <operand>
> 
> are so different from 
> 
> 	x = x <op> operand
>
> I imagine that many hours of time will be wasted explaining to
> Pythion newbies on comp.lang.python why these unpleasant side-effects
> occur.

Wouldn't it be much harder to explain to newbies why
x = [3]
x += [4]
Makes a copy of x?

> > And then there's
> > 
> >     tup = ()
> >     lst = []
> >     tup += (33)
> >     lst += [33]
> > 
> > The last two lines look about the same but have different semantics! In
> > pure augmented assignment the semantics would be parallel, and would be
> > exactly what is suggested by the two characters of the "+=" operator.
> > 
> > Bob
> > 
> > * <wink>(TM) used without permission.
> 
> This also confuses me, but then I'm a bear of very little brain <wonk>*.
> Surely this can't be the intention of the PEP?  Are immutables going
> to be mutable-in-place now?  You must have misunderstood!  Since 1.5.2
> gives:
> 
> >>> tup = ()
> >>> tup = tup + (33)
> Traceback (innermost last):
>   File "<pyshell#6>", line 1, in ?
>     tup = tup + (33)
> TypeError: illegal argument type for built-in operation
> 
> why should there be *any* legality to the augmented assignment
> operator applied to tuples?

As someone else said, that should be (33,), and is perfectly o.k. in
Python 1.5.2. This is exactly the intention of the PEP: += on mutable
and immutable types have a different effect.

> This is the heart of it as far as I'm concerned.  In 1.5.2 and preceding
> implementations we have got used to the idea that a variable is, in fact,
> a pointer (or reference) to a value, and that if we "modify the value of
> a variable" we are actually computing a new value and then replacing
> the current variable's content with a reference to that new value.

But now we don't have to anymore! Isn't that cool! Much faster with
big structures.

> I've used such languages before -- in fact, I was a long-term Icon
> fanatic -- and I just don't feel there's ANY room for in-place
> modification of this nature, which goes counter to the whole semantics
> of assignment.

But this isn't assignment.

> In point of fact, my belief is that this proposal, if it goes through,
> puts an *implementation bias* into the language definition whoch goes
> far beyond the ugly but acceptable "print >>".  This is being done, I
> suspect, to make certain operations more efficient by avoiding the need
> to create a new object.  It sucks!

You want the language to stay completely "clean" even though that hurts
pragmatism. I don't think that's Pythonic. Making certain operations more
efficient is a good thing, IMO.

> As far as I'm concerned, if you need to modify objects in place *for
> efficiency reasons* then you should expect to have to put up with a
> loss of readability.

Why??

> Efficiency should have little to do with the
> language definition: that's an implementation issue.

And readability is a language issue. But you say we have to put up
with loss of readability if we want efficiency...



Sorry for repeating my points far too much, but I feel some people are
spreading FUD just because they see something new introduced. It's *new*,
dammit, it doesn't work exactly like you're used to, but that doesn't mean
it can't be good. You're trying to make people's life harder for some ideal
of cleanliness. In my opinion.

-- 
Remco Gerlich,  scarblac at pino.selwerd.nl
Hi! I'm a .sig virus! Join the fun and copy me into yours!