[Python-Dev] Fwd: summing a bunch of numbers (or "whatevers")

Tim Peters tim.one@comcast.net
Sun, 20 Apr 2003 22:48:43 -0400

[Guido, making right decisions again, and I'll correct the details <wink>]
> ...
> I've never liked reduce() -- in its full generality it causes hard to
> understand code, and I'm glad to see sum() remove probably 80% of the
> need for it.

97.2%, actually.

> ...
> I'm not too worried that people will ask for prod() as well.  And if
> they do, maybe we can give them that too;

They will ask, but let's resist that one.

> there's not much else along the same lines (bitwise or/and; ha ha ha)

xor reduction is the key to the winning strategy for the game of Nim, so
expect intense pressure from the computer Nim camp.

> ...
> There's a bunch of statistics functions (avg or mean, sdev etc.) that
> should go in a statistics package or module together with more
> advanced statistics stuff -- it would be a good idea to form a working
> group or SIG to design such a thing with an eye towards usability,
> power, and avoiding traps for newbies.

Very big job, unless you leave the "advanced" stuff out.  Note that there
are many stats packages available for Python already, although some build on

> ...
> (A minority view that I can't quite shake off: since the name sum()
> strongly suggests it's summing up numbers, sum([]) should be 0 and no
> second argument is allowed.

That's my view, so it's quite possibly the correct view <wink>.  Numbers is
numbers.  sum(sequence_of_strings) hurts my brain, just as much as if we had
a builtin concat() function for pasting together a sequence of strings, and
someone argued that concat(sequence_of_numbers) should return their sum
"because they're both related to the '+' glyph in a syntactical way" (that
they both relate to methods named __add__ is beyond instant explanation to a