One last shot at the Augmented Assignment PEP

[Steve Holden]

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 :-(
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.

As a brief aside, I can't help feeling it ought to be easier to
locate the PEP list from both www.python.org and www.pythonlabs.com.
On the former, all a search for PEP reveals is a list of python-dev
summaries.  The latter doesn't even appear to have a search feature
at all.  This all adds to the feeling that "these people have something
to hide" -- which I don't really believe.  Compared with Microsoft's
process, for example, the Python world sa model of openness.

For the record, see http://python.sourceforge.net/peps/

> As a proponent of *true* augmented assignment, though, I suggest we
> rename that new feature in Python to something more appropriate to the
> definition. Like "sometimes-augmented sometimes-assignment". Or "totally
> new operators having little to do with assignment".

:-)

> 
> Note that in
> 
>     a = []
>     a += [33]
> 
> neither "+" (list concatenation) nor "=" (assignment) are performed
> <wink>*.
> 
> Furthermore, in
> 
>     a = []
>     b = a
>     a += [33]
> 
> b changes. Neither "+" (list concatenation) nor "=" (assignment), would
> affect b at all.
> 

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.


> Since neither assignment nor the operation suggested by the binary
> operator bundled with the "=" take place in the above examples, and
> since new side effects occur that would not happen in pure augmented
> assignment, how could it be appropriate to call it such?
> 

It will be called what the BDFL wants it to be called...

> 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?

However, to quote the PEP:

    "The idea behind augmented assignment in Python is that it isn't
    just an easier way to write the common practice of storing the
    result of a binary operation in its left-hand operand, but also a
    way for the left-hand operand in question to know that it should
    operate `on itself', rather than creating a modified copy of
    itself."

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.

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.

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!

Sure enough, a little further down the PEP we see:

    "To work around this problem, the packages currently have to use
    methods or functions to modify an object in-place, which is
    definitely less readable than an augmented assignment expression. 
    Augmented assignment won't solve all the problems for these
    packages, since some operations cannot be expressed in the limited
    set of binary operators to start with, but it is a start. A
    different PEP[2] is looking at adding new operators."

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.  Efficiency should have little to do with the
language definition: that's an implementation issue.

It's not that I'm against the introduction of in-place modification
where programs will benefit.  It's just that I don't think the syntax
should be such as to mislead naive programmers in the way this proposal
will.  I would *far* prefer augmented assignment to have the standard
semantics of the existing binary operations, and then use a modified
syntax such as

	a +!= [33]

to implement the semantics that currently proposed.  If PEP 203 makes
it in to the language I suspect my personal solution will be to simply
ignore the "feature".  But I do feel we are laying down trouble for
future Python learners due to the totally counter-intuitive nature of
this porposal.

Well, I don't imagine that my little rantings are going to alter the
course of Python history, but thanks for giving me the chance to at
least express my feelings!

regards
 Steve

* My way of indicating that I feel something is going wonky :-)
-- 
"In-place value modification?  Can you say 'blerch'?"
703 967 0887      sholden at bellatlantic.net      http://www.holdenweb.com/