[Python-ideas] Fast sum() for non-numbers - why so much worries?

[Ronald Oussoren]

On 11 Jul, 2013, at 21:20, Terry Reedy <tjreedy at udel.edu> wrote:

> On 7/11/2013 1:53 AM, Ronald Oussoren wrote:
>> 
>> On 11 Jul, 2013, at 7:27, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 
>>> It does count; it's a language change.  It is not a bug-fix in which
>>> the implementation is brought into line with the language definition.
>> 
>> That doesn't mean that using += instead of + in sum isn't a valid change
>> to make for 3.4.
> 
> Breaking code in the way this would do, would require a PEP and deprecation cycle. I do not anticipate approval for a general change.

I agree. At the time I wrote this I didn't know that in numpy + and += have slightly different semantics w.r.t. coercion of array element types. That means that using += in sum() would change the behavior of calling sum on a sequence of numpy arrays, and given that we try hard to maintain backward compatibility this means that this particular change probably won't happen.  More so because the documentation clearly indicates that sum() is intended to be used with numbers and the change is meant to change the behavior for non-numbers (in particular lists).

> 
> A specialized change such that sum(iterable_of_lists, []) would extend rather than replace [] might be done since the result would be equal to the current result, just faster, and since [] must be nearly always passed without aliases that depend on it not changing. Even that should have a deprecation warning.

I don't think that a deprecation warning would be needed, as long as start got copied before extending it.  

> 
> Tuples could be linearly summed in a list with .extend and then converted at the end. I don't believe that would be a semantic change at all.

It would make the implementation of sum more complicated.

There is clear historical evidency that sum is not intented to be fast for everything that supports the + operator, calling sum on a sequence of strings raises an exception instead of trying to special case this.

> 
>> BTW. This thread has been rehashing the same arguments over and over again,
>> and it's pretty likely that most core devs have stopped following this thread
> 
> Right, I just happened to pick this post because you are also a core dev.

I am, but that doesn't mean my opinion caries a lot more weight in this discussion ;-).  The higher profile core devs are conspicuously absent from this discussion, which is why I wrote that someone needs to write a summary of the discussion.  I'm not that someone though.

Ronald