list problem

Alex Martelli aleax at
Tue Sep 24 16:13:41 CEST 2002

Duncan Booth wrote:

> Alex Martelli <aleax at> wrote in
> news:_FZj9.158106$pX1.5692316 at
>> I _do_ think that reduce(operator.__add__, ...) is the only
>> really frequent use of reduce, with such dominance that it might
>> even be worth having as a built-in -- clearest and fastest.  It
>> might even specialcase _strings_ in particular, turning the op
>> into a ''.join in this case... just musing...
> The simplest thing could be to modify operator.add to accept any number of
> arguments. Then you could use operator.add(*aList) to add up or
> concatenate as appropriate all the elements of the list.

I suspect that would convert aList to a tuple (but I'd have to
double check the internals to make sure) thereby negating any
performance benefits.  Maybe it would be better to allow operator.add
to be called with ONE argument (must be iterable and not empty), OR two 
(working just like it works now, in this case).  This should avoid
any issue with type-conversion list-to-tuple or whatever.

> It still wouldn't be as fast as ''.join though unless you special cased
> it, and it might be hard to special case it effectively: you would have to
> check the types of all the objects in the list before deciding whether or
> not to use join.

Yes, I could write a class X, with an __add__ that's able to accept a
string argument (thus an instance of X would work with a 
reduce(operator.add ...) but is not a string (thus would fail if one of the 
items in a list passed to ''.join was an instance class X).  But I could 
also simply check the first argument: if a string, FIRST try the equivalent 
of ''.join -- if  that raises a TypeError, fall back to looping on 
addition.  A tiny price to pay, I think, for the rare/weird case of a class 
with an __add__ that, for the benefit of helping newbies avoid the
single most likely performance pitfall of Python.  But I'm not sure
it's such a good idea anyway.  Mostly, the hypothetical builtin sum
or one-argument operator.add would be used to tot up numbers, though
of course as a nice side effect of polymorphism it would also work
for other types (maybe horribly slow for big lists of small strings:-).


More information about the Python-list mailing list