[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/) _______________________________________________ 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
