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

[Michael Chermside]

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. This all started with your claim that sum() was a replacement
for most reduce() uses. 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__. So trying to make it work well for non-numbers is just
arguing over whether it replaces 75% of all reduce() uses, or 85% of
them. Who cares?

Remember, *ANY* use of sum() can be replaced by a simple, readable,
three line for loop:

    total = <starting-value>
    for i in <list-of-values>
        total += i

And for that matter, other uses of reduce are similarly easy to write
as a loop. I'm not saying reduce() is useless, just that it's not
worthwhile to expend effort trying to cover every last use case with
things like sum() or product() -- one can always write the loop instead.

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.

_IF_ we follow Tim's advice and think of sum() as designed to add up
numbers (as the name implies), then the corner cases are obvious:
summing a list of 1 item should return the item, and summing a list of
0 items should return 0. If we think of sum as a form of reduce() that
operates only on the __add__ operator, then we need to make other
choices for these corner cases, and the people using it to add numbers
will suffer the small indignity of having to recall how the corner
case works.

Honestly, the only case I even remotely care about is concatenating
strings -- as far as _I_ am concerned, everyone else can just write out
the loop or provide their own "sum_matrix()" method. And if I understand
correctly, there's no plan to make sum() "just work" for concatenating
strings (besides which, we'd still need to handle the empty list). So
I'm in favor of REMOVING the second argument of sum() for python 3000,
unless it was kept purely for "backward compatibility" reasons, which
would be defeated by changing it's behavior.

(And if this doesn't convince you, then so be it... this isn't a
particularly important issue.)

-- Michael Chermside