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

Alex Martelli aleax@aleax.it
Sun, 20 Apr 2003 12:10:07 +0200


On Sunday 20 April 2003 10:18 am, Brett Cannon wrote:
   ...
> I think part of the trouble here is the name.  The word "sum" just
> automatically causes one to think math.  This leads to thinking of
> multiplication, division, and subtraction.  But Alex's proposed function
> does more than a summation by special-casing the concatentation of
> strings.

Actually it does more than summation because, in Python, + does
more than summation.  E.g., my function needs absolutely no
special-casing whatsoever to produce

>>> sum([[1,2],[3,4],[5,6]])
[1, 2, 3, 4, 5, 6]

I special-cased the "sum of strings" just for performance issues,
nothing more!

> Perhaps renaming it to something like "combine()" would help do away with
> the worry of people wanting a complimentary version for multiplication
> since it does more than just sum numbers; it also combines strings in a
> very efficient manner.  I mean we could extend this to all built-in types
> where there is a reasonable operation for them (but this is jumping the
> gun).

sum already works on all types, built-in or not, for which + and operator.add
work -- thus, 'combine' sounds too vague to me, and the natural way to
"extend this" to any other type would be to have that type support + (by
defining __add__ or in the equivalent C-coded way).


> And as for the worry about this being a built-in, we do have divmod for
> goodness sakes.  I mean divmod() is nothing more than glorifying division
> and remainder for the sake of clean code; ``divmod(3,2) == (3/2, 3%2)``.
> This function serves the same purpose in the end; to allow for cleaner
> code with some improved performance for a function that people use on a
> regular enough basis to ask for it constantly on c.l.p .

I think this is a very good point.  The worries come from the fact that we
already have many built-ins (44 functions at last count -- counting such
things as exception classes doesn't seem sensible) -- but is it a good idea
to exclude 'sum' because we have more exotic built-ins such as 'divmod',
or semi-obsolete ones such as 'apply'?

I've only seen Raymond objecting to 'sum' as a built-in (naming it 'add'
might be just as fine, and having it accept the same argument patterns
as max/min probably useful) -- though I may have missed other voices
speaking to this issue -- so perhaps it's best if he clarifies his objection.


Alex