restriction on sum: intentional bug?

[Ethan Furman]

Steve wrote:
> On Oct 17, 8:28 pm, Tim Chase <python.l... at tim.thechases.com> wrote:
> 
>>Christian Heimes wrote:
>>
>>>Alan G Isaac wrote:
>>>
>>>>On 10/16/2009 5:03 PM, Christian Heimes wrote:
>>>>
>>>>>It's not going to happen.
>>>>
>>>>That's a prediction, not a justification.
>>
>>>It's not a prediction, it's a statement. It's not going to happend
>>>because it violates Guido's gut feeling as well as the Zen of Python.
>>
>>I'm not sure how it violates ZoP...particularly
>>
>>Simple is better than complex.
>>   [complex is special casing or explaining why there's an error]
>>Special cases aren't special enough to break the rules.
>>   [raising an error is a special case]
>>Although practicality beats purity.
>>In the face of ambiguity, refuse the temptation to guess.
>>   [there's nothing ambiguous about sum() meaning "+"]
>>If the implementation is easy to explain, it may be a good idea.
>>   [sum(lst_of_strs) should do exactly what it says..."+" 'em]
>>
>>-tkc
> 
> 
> Sorry about the late reply.
> 
> You overlooked "There should be one-- and preferably only one --
> obvious way to do it.",  which in this case is join()

That doesn't mean *only* one obvious way to do it, and more importantly 
it *does not* mean *only one way* to do it.


> To me the current implementation is blatantly correct. sum is an
> operation on a list of numeric values, returning a numeric value -
> this is why we have the seemingly strange "".join() rather than [].join
> ("")
> 
> I think duck typing is wonderful so long as its specific applications
> make sense. 

Duck typing is about not guessing what will make sense, or what needs 
will arise, to the users of our code.


> We don't handle integers being passed to len() do we?
> Technically we could return the number of digits but it wouldn't make
> sense as len() works on iterables.

Ints do not have a __len__ method, so why should len() work on them? 
Strs, on the other hand, do have an __add__ method.

~Ethan~