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

[Guido van Rossum]

On Mon, 14 Mar 2005 19:16:22 -0500, Tim Peters <tim.peters at gmail.com> wrote:
> [Eric Nieuwland]
> >> Perhaps the second argument should not be optional to emphasise this.
> >> After all, there's much more to sum() than numbers.
> 
> [Greg Ewing]
> > I think practicality beats purity here. Using it on
> > numbers is surely an extremely common case.

[Tim Peters]
> I'd personally be delighted if sum() never worked on anything other
> than numbers.  That makes it easy to understand, easy to document,
> easy to remember, obvious at first sight, and straightforward to
> implement.  Everything a framework isn't, but it's not a bad thing to
> have *something* that actually means exactly what it looks like it
> says <0.5 wink>.

Unfortunately this started when I claimed in my blog that sum() was a
replacement for 80% of all reduce() uses. This was countered by
someone who pointed out that without a 2nd argument it doesn't work
for non-numbers that happen to implement __add__, and I'm not sure he
was aware you could make it work *with* a 2nd argument (I know *I* had
forgotten all about that :-).

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. Alex's use case for a nonzero 2nd argument:

  total = 0
  for lst in sequence_of_lists:
      total = sum(lst, total)

can be just as easily written like this:

  total = 0
  for lst in sequence_of_lists:
      total += sum(lst)

and I think that's actually clearer (since the reader doesn't have to
know about the 2nd argument's meaning).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)