restriction on sum: intentional bug?
ethan at stoneleaf.us
Tue Oct 27 17:02:09 CET 2009
> 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]
> 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.
More information about the Python-list