Augmented Assignement (was: Re: PEP scepticism)

[Carsten Geckeler]

On 29 Jun 2001, David Bolen wrote:

> Carsten Geckeler <uioziaremwpl at spammotel.com> writes:
>
> > The problem which some people have with augmented assignment is not that
> > they exist, but that they do not work as they expect (at least from the
> > POV of some readers).  I expect that
> > 	ident op= expr
> > works like
> > 	ident = ident op expr
> >
> > At least that's what I'd have expectd comming from other programming
> > languages.
>
> Of course, one interesting point is that while you may think the above
> if coming from, say, C, what "ident = ident op expr" means in C is not
> what "ident = ident op expr" means in Python.

Yes, that's completely true.  I can accept, that Python work differently
in many cases.  Actually I love Python's object stuff.  That's something
more natural that in many other languages.  And I can accept, that objects
(which are bound to different variable names) can be changed (like with
l.extend).

The point is not that Python differs from C (or other languages), but that
the two statements above work differently.  I can accept that, of course
(well I have to, I thing ;) ).  But, when I write the following three
statements,
	l = l + [3, 4]
	l += [3, 4]
	l.extend([3,4])
it seems more logical to me, that the first two do the same than the last
two.  I know, of course, that the last two do the same.  But anyway, the
first two just _look_ more the same.

> In C it has the result of changing data (in either case) that is
> stored in a named location ident, in Python the long form just rebinds
> the reference ident to a new object and doesn't touch the original
> object.  The short form can actually get closer to the C idiom if the
> object is mutable.
>
> So I wonder if some of the confusion is people familiar with other
> language's augmented assignment trying to extrapolate that into Python
> and then running into the pre-existing differences in assignment
> versus binding?

No, that's at least no problem for me (see above).

Cheers, Carsten
-- 
Carsten Geckeler