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

Guido van Rossum gvanrossum at gmail.com
Tue Mar 15 18:07:50 CET 2005

> > Unfortunately this started when I claimed in my blog that sum() was a
> > replacement for 80% of all reduce() uses.

> That's probably where the error lies, then. When it was introduced,
> sum() was for summing numbers.

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.

> Whether summing numbers is 80% of all
> uses of reduce or not is debatable, but I can't say I care. But I *do*
> care that this claim was taken as meaning that sum() was *intended*
> specifically to replace 80% of all reduce() uses - a clear
> misinterpretation.

Not intended, but it happens to address many cases.

> > I think the conclusion should be that sum() is sufficiently
> > constrained by backwards compatibility to make "fixing" it impossible
> > before 3.0.
> It seems wrong to be talking about "fixing" sum so soon after it was introduced.

3.0 is soon?!?

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

More information about the Python-Dev mailing list