One last shot at the Augmented Assignment PEP

[Steve Holden]

Eric Jacobs wrote:
> 
> In article <39BFD47F.FBC4528E at holdenweb.com>, Steve Holden
> <sholden at holdenweb.com> wrote:
> [snip]
> >
[snippety snip]
> 
> 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.
> 
My mistake.  Thanks.

> > 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.
> 
This expresses my point rather better.  I really don't like the way that
the new augmented assignment operators are free to modify objects in-place
while they still look like assignments.  Assignment just doesn't work
this way -- yet :-(

> > 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?)
> 
Precisely.  I use list.extend() all the time, and don't have any problems
with the fact that if I've assigned the list to some other variable then
it too will experience a change of value.

This is the way I think about assignment in Python and Icon, and the new
operators introduce non-assignment semantics to apparently-assignment
operators.

> > 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.
> 
I've never thought that the proposal was maliciously motivated, but I
really do feel its effects will be unfortunate.

> > 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.
> 
Well, true.  But to make such analysis of Python programs gives you all
the same problems that attempting to introduce static typing does.  What
about threading, for example?

I wouldn't complain about such an optimization if correctly performed,
but I wouldn't like to have to write the optimizer!

> > 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.
> 
Right, that's settled then.  Will you write the PEP, or shall I?  :=)

> > 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.
> 
Yup.  I suppose the real dastardly part of the PEP is this:

    "To make this possible, a number of new `hooks' are added to Python
    classes and C extension types, which are called when the object in
    question is used as the left hand side of an augmented assignment
    operation. If the class or type does not implement the `in-place'
    hooks, the normal hooks for the particular binary operation are
    used."

In other words, you have to know whether each type possesses the new
hooks in order to be able to predict the effects of the operations.

> 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.)
> 
This is definitely a livable alternative, for me at least.  It's only
just becoming obvious to me how strongly I feel about this!

> > 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?
> 
Oh, dear.  You are indeed correct.

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

Thanks again!

regards
 Steve
-- 
Helping people meet their information needs with training and technology.
703 967 0887      sholden at bellatlantic.net      http://www.holdenweb.com/