restriction on sum: intentional bug?

[Steve]

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()

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. 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.