[Python-Dev] Re: Rationale for sum()'s design?
tjreedy at udel.edu
Tue Mar 15 17:25:52 CET 2005
"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
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
> 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
More information about the Python-Dev