RetroSearch Browse

Tue Mar 15 18:07:50 CET 2005 · https://mail.python.org/pipermail/python-dev/2005-March/052197.html

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

[Paul]
> 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/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-March/052197.html below:

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