incrementation operators?

[Thomas Wouters]

On Sun, Aug 13, 2000 at 10:31:43AM -0400, Colin J. Williams wrote:

> The PEP gives a full description of the various operators, but provides no
> rationale for their introduction.

A previous version of the PEP did include that. In fact, it was an
incomplete story and *only* included the rationale ;) But Guido asked for a
more technical PEP, because there is no doubt in his mind that augmented
assignment are a good thing and should be included in Python. 

You can browse the CVS tree, including old revisions on SF. The revision I'm
talking about can be found here:

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/pep-0203.txt?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=python

Mind the linebreaks ;)

> I wonder how frequently this sort of operation in place would be used in
> practice. Does the frequency of likely use balance the increased clutter? 

Well, how often have you yourself used 'list.extend' or 'list.append' ?
I personally think

  list += [element]

and

  list += olist

look better (== more like what they actually do) than 

  list.append(element)

and

  list.extend(olist)

Especially since even though the methods are functioncalls, they don't
return any useful value. 

> One of the attractive features of Python is its relative simplicity. 
> Would we lose some of this simplicity for little practical gain?

We lose some simplicity, yes, but not much, and I think the price is worth
it, myself. The augmented assignment operators, all eleven of them, are
obvious combinations of assignment and a binary operation. There is no large
or unnatural step to be made from the current Python to
Python-with-augmented-assignment.

> These operators exist in other languages.  Is there a justification for
> including them in Python?

Yes, Even asside from people expecting them :-) In fact, people expecting
them is not a reason to include them at all -- auto-increment/decrement
operators are *not* added, eventhough people expect them. The two main
reasons (as far as I'm concerned, other opinions might differ) for augmented
assignment are simplicity and in-place editing of objects. Simplicity in
that you can write 

 something[orother(to, something[else])] += newval

rather than the longer, less obvious (because you have to look closely to
see if the two indices are actually the same) and more errorprone:

 something[orother(to, something[else])] = something[orother(to,
						something[else])] + newval

And because the augmented versions of the binary operators can be seperately
overloaded, in both Python and C, large objects and other objects that wish
to do so can make themselves easily 'mutable', without having to resort to
methods (see the list argument above.) Note that objects don't *have* to
overload the augmented operations! If they don't, code falls back to the
normal binary operation.

> I hope that I am not too late for some sober second thoughts.

Well, it seems Guido and Tim have been wanting augmented assignment for
years, and only waited for someone to write the patch. Second thoughts about
the implementation are possible. Second thoughts about specific semantics
might be possible, though I've given these very good and long thought and I
think I've covered all options. But unless someone brings up real
fundamental issues wrt augmented assignment, I don't think you can stop it
from going into 2.0. It's up to Guido, and he's all for it.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!