One last shot at the Augmented Assignment PEP

[Eric Jacobs]

In article <39BFD47F.FBC4528E at holdenweb.com>, Steve Holden
<sholden at holdenweb.com> wrote:
[snip]
> 
> 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?

Nope, the proposal won't do that.

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

Bob made a typo in the last post. It should say:

>>> tup = tup + (33,)

(note the comma), which is legal in 1.5.2. (33) evaluates to an integer,
not a tuple.


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

No. You can modify the value of an object that's referenced by a variable, 
or you can modify the variable to reference a different object. The issue
is that it has always been (and should always be) clear which one of the
two very different modifications are occuring.

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

Is list.extend() okay? If there's no in-place modification at all, I'd
say you'd have a pure functional language. (Of course, list.extend()
doesn't look like assignment -- is that what you're saying?)

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

Much worse, I agree. The motivations for the changes are not flawed,
however the design is a disaster.

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

Well, no, I don't think readability has to be lost. A smart interpreter
might execute

  l = []
  for x in range(10):
     l = l + [x]

as

  l = []
  for x in range(10):
      l.extend([x])

for efficiency reasons. But if it wasn't known that the only reference
to l is l, than this optimization couldn't be made. Optimized or no,
it should behave the way the code indicates.

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

Better yet, drop the equal sign, because it denotes assignment, and
there should never be an assignment happening if the user is trying to
do a modification.

I'd vote for:

   a +! [33]

to address the readability issue and provide more logical consistency
to the syntax used for object modification.

> to implement the semantics that currently proposed.

Which are inconsistent, because sometimes "assignments" assign and
sometimes they do not. Better be clear and have two completely
different sets of operators to do the two completely different things.

Although having two sets of binary operator statements seems like it
would be more confusing to beginning programmers, in the long run it
would pay off, I believe. (And probably in the short run, too, if
people start substituting x += for x = x + and wondering why everything
starts acting strange.)

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

Hasn't it already made it for 2.0?

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

Consider them expressed!