[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] + ... _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com