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. -- http://mail.python.org/mailman/listinfo/python-list
