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

[Brett Cannon]

[Alex Martelli]

> On Sunday 20 April 2003 02:01 am, Brett Cannon wrote:
>    ...
> > So I have no fundamental issue with the proposed function, but I don't
> > find a huge need for it personally; I always do the looping solution
> > (jaded against the functional stuff from school =).
>
> Looping is what I'm doing these days, but while fastest it's not terribly
> convenient.  And it took me a while to learn to avoid reduce for that...
>

True, but "explicit is better than implicit".  But don't take this to mean
that I don't think that your proposed function is not good; I do think it
has merit.

<snip>
> Agreed on collocation -- itertools or math would be inappropriate, and
> builtins best, but since there are already so many builtins many are
> understandably reacting badly to the idea of adding anything there.
> So, if builtins are to be considered untouchable, I'd rather have sum
> in operator (where it does sort of fit, I think) than do without it.
>

Fair enough.  Either that or a new module.

<snip>
> So, let's see if I can express this more clearly...:
>
> It's not a question of tyranny of anybody -- it's a question of the degree
> of abstraction required to find "reduce(operator.add, L)" the ``one
> obvious way'' to sum numbers being quite a bit above everyday thought
> habits.  If we say that "the one obvious way" is a loop it becomes hard
> to justify why the one obvious way to find a maximum is max(L) rather
> than a perfectly similar loop -- after all "sum these numbers" and "find
> the largest one of these numbers" are tasks with perfectly comparable
> frequency of applicability in everyday programming tasks and perceived
> complexity.  (My implementation for sum is a small copy-past-edit job
> on that of max/min, removing the special-case the latter have when
> called with >1 argument and adding one to delegate to ''.join for the
> specific purpose of summing instances of PyBaseString_Type -- the
> structure is really very similar).
>

That's better. =)  Comes off less as "let's add this to make newcomers
happy" and more as "this will simplify good code".  The latter is a always
a good thing.

I have an idea to respond to the whole "everyone will want prod() next"
idea, but I will put that in another email to try to keep this thread
coherent.

-Brett