incrementation operators?

[Tim Peters]

[Colin J. Williams]
> ...
> The PEP gives a full description of the various operators, but
> provides no rationale for their introduction.
>
> 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?

I was thinking about that yesterday (for about the 10,000th time <wink>)
while writing this loop:

    for i in range(pad):
        term = term * ((i-d) * b) / (c*(i+1))
        sum = sum + term
        if term == 0:
            sum = sum >> pad
            break

and wishing like mad I could have written

    for i in range(pad):
        term *= ((i-d) * b) / (c*(i+1))
        sum += term
        if term == 0:
            sum >>= pad
            break

instead.  The latter reduces the clutter I *care* about on 50% of the lines:
mental clutter.  At the algorithmic level, I *think* "add term to sum", and
"shift sum right by pad" etc, not "add sum to term and then replace sum by
that" etc.  I don't really care about the savings in typing!  It's the
ability to say what I *mean* more directly.

So it will be used frequently, at least by me <wink>.  The semantic clutter
is one general new rule (learning what += means, then learning that *= etc
mean the obvious variations on that); the internal implementation clutter is
relatively immense but pretty much the same business of implementing it once
then plugging in minor variations repeatedly.  Thanks to Thomas Wouters,
that "hard part" is done now.

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

It's a tradeoff, of course, and not all people will judge that the same way.
In this case I think it's a major gain in expressive simplicity (how much
hassle it takes to say what I mean, and to later *reconstruct* what I meant
from what I was allowed to say <0.5 wink>), versus a minor blow to syntactic
minimality.  You may not agree, and that's why Guido is elected Benevolent
Dictator for Life.

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

Guido reports they're the single most-requested new feature in Python's
history, so even if you don't like dictators, it's the Will of the People
<wink>.

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

Probably too late by about 5 years, which is about how long ago Guido told
the Numeric Python people he would eventually add this.  When x and y are,
for example, matrices with millions of elements, the *semantic* difference
between

   x = x + y

and

   x += y

can be the difference in whether the program can run at all:  a matrix class
can arrange so that the latter overwrites x in-place, but the former will
allocate another multi-million element temp array to hold the sum, only to
copy the temp over x immediately and then deallocate it.  That's a case
where the "mental clutter" of not being able to say "add y to x" directly
translates into megabytes of RAM and cache clutter too.

So while this debate has been going on for years, it essentially ended in
Guido's mind in the mid-90's.  I think he stopped at just the right place,
too.  While everyone thinks "add 1 to i" from time to time, *nobody* thinks
"plus plus i" <wink>.

"incr-i"-is-a-nice-thing-to-think-but-remains-unspeakable-ly y'rs
    - tim