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

[Tim Peters]

[Guido van Rossum]
> Um, Python doesn't provide a lot of special support for numbers apart
> from literals -- sum() should support everything that supports the "+"
> operator, just like min() and max() support everything that supports
> comparison, etc.

The discussion in the patch that introduced it may be illuminating:

    http://www.python.org/sf/724936

>From your (Guido's) first comment there, it seems clear that sum() was
originally intended only for numbers.

Then it got generalized.

Then sequences of strings specifically were disallowed.

Then it was suggested that mention of a sequence of lists or tuples be
removed from the docs, and that datetime.timedelta() be used in
examples where "0" didn't make sense as the identity.

Then Alex changed it to disallow any sequence of sequences.

Then you suggested either specifically disallowing only sequences of
lists, tuples or strings (but allowing all other sequence types as
elements), _or_ going back to disallowing only sequences of strings.

Alex took the latter suggestion, and that's where it ended.

The closest thing to a design rationale I found is Guido's
Pronouncement here, and I think it covers most issues raised this time
around:

    http://mail.python.org/pipermail/python-dev/2003-April/034853.html

The optional argument was my fault.  The rest was Guido's <wink>:

    If we add an optional argument for Tim's use case, it could be used in
    two different ways: (1) only when the sequence is empty, (2) always
    used as a starting point.  IMO (2) is more useful and more consistent.

Nobody opposed that.  I remember silently agreeing at the time, just
because #2 had precedent in other languages, and seemed easiest to
explain:

    sum(seq, start=0)  same-as  start + seq[0] + seq[1] + ...