[Python-Dev] Fwd: summing a bunch of numbers (or "whatevers")
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.
> 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