incrementation operators?

[Colin J. Williams]

Thomas,

Many thanks for the responses of Alex and yourself.

I think you make a case for the list augmentation, but I still wonder about the
frequency with which the simple arithmetic incrementing operators are used in
other languages.  However, Guido has spoken and so I will not pursue that.

Regarding the use of the += with lists.  It seems that:

a= [1, 2]
a+= 3                  is equivalent to a.append(3)
a+= [4]                is equivalent to a.extend([4])

Suppose one wishes to do a.append([5]).  It would appear that one would have to
return to the existing syntax.

Thanks again

Colin W.

Thomas Wouters wrote:
> 
> 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!