[Python-Dev] Re: Rationale for sum()'s design?

[Terry Reedy]

"Michael Chermside" <mcherm at mcherm.com> wrote in message 
news:20050315051257.a9dv3dxzbhk4sswo at mcherm.com...
> Tim writes:
>> I'd personally be delighted if sum() never worked on anything other
>> than numbers.
>
> Guido writes:
>> I think the conclusion should be that sum() is sufficiently
>> constrained by backwards compatibility to make "fixing" it impossible
>> before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is
>> only used for empty lists.
>
> Guido, I find myself far more convinced by Tim's suggestion than
> yours.

I am leaning in that direction too.

>This all started with your claim that sum() was a replacement
> for most reduce() uses.

To me, the proper general replacement for the doubly broken builtin reduce 
would be a properly-defined functional.reduce (a subject for another post), 
not a bloated sum ;-)

> We all agree that it works fine for summing up
> numbers. We all agree it DOESN'T work for any case where the operator
> isn't __add__.

However, __add__ can be defined to mean anything.  I'd hate to see people 
choosing '+' as an operator symbol merely to get reduction disguised as 
summation.

[snip]
> What I think is MORE important is that sum() have predictable behavior
> in the degenerate cases. And by "predictable", I mean predictable by
> a newbie user or one someone who hasn't looked at the docs for sum()
> for the past year and mostly remembers what it does only because the
> name is so blatantly obvious.

Nick's very unmemorable a,b,c,d rules shows the complications that 
reduction-disguised-as-summation can lead to.

Terry J. Reedy