[Python-Dev] sum(...) limitation

[MRAB]

On 2014-08-02 16:27, Steven D'Aprano wrote:
> On Sat, Aug 02, 2014 at 10:52:07AM -0400, Alexander Belopolsky wrote:
>> On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano <steve at pearwood.info> wrote:
>>
>> > String concatenation with + is an attractive
>> > nuisance for many people, including some who actually know better but
>> > nevertheless do it. Also, for reasons I don't understand, many people
>> > dislike or cannot remember to use ''.join.
>> >
>>
>> Since sum() already treats strings as a special case, why can't it simply
>> call (an equivalent of) ''.join itself instead of telling the user to do
>> it?  It does not matter why "many people dislike or cannot remember to use
>> ''.join" - if this is a fact - it should be considered by language
>> implementors.
>
> It could, of course, but there is virtue in keeping sum simple,
> rather than special-casing who knows how many different types. If sum()
> tries to handle strings, should it do the same for lists? bytearrays?
> array.array? tuple? Where do we stop?
>
We could leave any special-casing to the classes themselves:

def sum(iterable, start=0):
     sum_func = getattr(type(start), '__sum__')

     if sum_func is None:
         result = start

         for item in iterable:
             result = result + item
     else:
         result = sum_func(start, iterable)

     return result

> Ultimately it comes down to personal taste. Some people are going to
> wish sum() tried harder to do the clever thing with more types, some
> people are going to wish it was simpler and didn't try to be clever at
> all.
>
> Another argument against excessive cleverness is that it ties sum() to
> one particular idiom or implementation. Today, the idiomatic and
> efficient way to concatenate a lot of strings is with ''.join, but
> tomorrow there might be a new str.concat() method. Who knows? sum()
> shouldn't have to care about these details, since they are secondary to
> sum()'s purpose, which is to add numbers. Anything else is a
> bonus (or perhaps a nuisance).
>
> So, I would argue that when faced with something that is not a number,
> there are two reasonable approaches for sum() to take:
>
> - refuse to handle the type at all; or
> - fall back on simple-minded repeated addition.
>
>
> By the way, I think this whole argument would have been easily
> side-stepped if + was only used for addition, and & used for
> concatenation. Then there would be no question about what sum() should
> do for lists and tuples and strings: raise TypeError.
>