Home Original page

PEP 322: Reverse Iteration (REVISED, please comment)

Michele Simionato mis6 at pitt.edu
Thu Oct 30 06:47:47 EST 2003 
Alex Martelli <aleax at aleax.it> wrote in message news:<EBVnb.376111$R32.12466927 at news2.tin.it>...
> math.sum would be arguably equivalent to sum as a built-in -- a
> tad less immediately accessible, but perhaps superior in that it
> immediately suggests it's about numbers only, so we'd avoid the
> icky performance trap you now get with sum(manylists, []) {which
> makes sum only 2/3 wonderful at best -- fine with numbers ONLY}.
> 

Too late :-( 

I see now that ``math.sum`` would have been a much better solution that a
new built-in. BTW, I remember this was discussed on the list, but
what was the argument against a polymorphic sum?

I mean, why it was not an option to implement a ``sum`` function 
calling:

1. int.__add__,float.__add__ etc. if the arguments where numbers;
2. string.join if the arguments where lists;
3. something to avoid the performance trap of list.__add__;
4. __add__ for custom defined objects.

BTW, I think the answer should go in the FAQ, since everybody looking
at ``sum`` for the first time would imagine it is polymorphic. I remember
you said your first idea was to make it polymorphic, but this was
rejected due to performances reasons. But why making ``sum`` to
special case according to the arguments (it would be enough to
check the type of the first argument, then we would get an error
if we try to add incompatible types, just as in "".join(["a", 1]))
was a bad idea?  

As you say, since ``sum`` is not polymorphic it makes more sense to put 
it in the ``math`` module. Now it is too late, but it is unfortunate.


                                    Michele
More information about the Python-list mailing list