Coding style and Python versions (was Re: Another itertool function?)

[Alex Martelli]

Roy Smith wrote:

> Alex Martelli <aleax at aleax.it> wrote:
>> No statistically significant / measurable difference.  The tiny
>> difference in conciseness is hardly compelling one way or another,
>> either.
> 
> I disagree (respectfully).
> 
> I'm all about writing code that's easier to read.  I'll admit that the
> += form is only marginally simplier to read, but marginal is better than
> nothing.

When what you're incrementing is a long name or an expression of
any substantial complication, then "left += right" may indeed offer
_significant_ advantages.

When what you're incrementing is "i" (as in the original question),
this is quite moot -- the alleged "increase in simplicity" is so
small that experimental error may be < 0...;-).

And I don't think that "one obvious way to do it" applies here --
just as, when I'm adding two numbers a and b, I'm pretty happy to 
get to choose between a+b and b+a depending on what's more readable
in the given context, quite similarly the choice between "i=i+1"
and "i+=1" is not necessarily preordained

> I tend to pick-and-choose from the XP menu, but one of the items I
> really like is "refactor mercilessly".  Why write a variable name twice
> when you can write it once?  Easier to read, and less error prone.  Have

When the variable name is short and sharp, writing it twice is no
problem -- and sometimes it can be more readable e.g. by showing
some parallelism:

    if override_with_new:
        current = incoming_new + increment
    else:
        current = current + increment

The choice between this, the "refactored" forms such as:

    if override_with_new:
        current = incoming_new
    current += increment

etc, etc, is indeed strictly one of readability, and thus of style.
I'm glad to have += as a CHOICE, but wouldn't like it as a MUST:-).


Alex