sum and strings

[Paddy]

Fredrik Lundh wrote:
> Paddy wrote:
>
> > Here is where I see the break in the 'flow':
> >
> >>>> 1+2+3
> > 6
> >>>> sum([1,2,3], 0)
> > 6
> >>>> [1] + [2] +[3]
> > [1, 2, 3]
> >>>> sum([[1],[2],[3]], [])
> > [1, 2, 3]
> >>>> '1' + '2' + '3'
> > '123'
> >>>> sum(['1','2','3'], '')
> > Traceback (most recent call last):
> >   File "<interactive input>", line 1, in ?
> > TypeError: sum() can't sum strings [use ''.join(seq) instead]
>

Hi Frederik,
> do you often write programs that "sums" various kinds of data types,
> and  for which performance issues are irrelevant?

I was asking if sum was indeed an optimization that did not work for
strings.
I was pointing out its affects on duck-typing.
I was hoping that someone might know the history and implementation of
sum and could point out the design decisions taken at the time and/or
discuss the merits of making sum accept strings. or indeed any type
that works with operator.add and that has an additive identity value.

Pythons designers seem to know and apply the advantages of having fewer
'themes' that can be applied with less constraints I am curious about
such a constraint on sum.

- Paddy.