[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
> 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
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