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

[Tim Peters]

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

> ...
> (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
newbie).