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

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


> I do see how it could be useful, though.  I don't necessarily see this as
> a built-in (although it wouldn't kill me if it became one).  I don't see
> it going into either the math or operator modules since it doesn't quite
> fit what is already there.  I initially thought itertools since it is
> basically working on an iterator, but I don't know if we want to change
> itertools from a module the provides functionality for outputting special
> iterators compared to working with iterators.

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.


> And as for the argument that other people are shocked it isn't already
> there... I just don't agree with that.  Just because people want it does
> not mean it is a good solution to a problem.  Tyranny of the majority and
> such.  =)

I must have expressed myself badly -- sorry.  What I meant to illustrate
is that sum (particularly as a built-in) would feel perfectly natural to
typical Python beginners -- it would instantly become "the one obvious
way" to deal with the common task of "sum these several numbers", as
well as the slightly less common one of "concatenate these many
strings" [many still balk at ''.join(manystrings), sum(manystrings) as I
coded it delegates to ''.join so it's almost equally fast] and the like.

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


Alex