Splitting lists

Steve Holden sholden at holdenweb.com
Fri Feb 28 13:35:46 CET 2003

"Brandon Beck" <bbeck13 at excite.com> wrote in message
news:3ac67cce.0302272006.3b721e27 at posting.google.com...
> Alex Martelli <aleax at aleax.it> wrote in message
news:<2Vl7a.329137$AA2.12321414 at news2.tin.it>...
> > appenders = tl.append, fl.append
> > for e in lst: appenders[not fn(e)](e)
> >
> > now isn't THAT more like it...?
> When I read this, I was immediately reminded of one of Guido's essays
> on optimization (http://www.python.org/doc/essays/list2str.html).  One
> of the takeaways I had from reading his optimization anecdote was that
> if possible you should attempt to use built-in functions with implied
> loops when possible.  So I immediately thought this should be faster:
>   func = lambda e, a=[t1.append, f1.append]: a[not fn(e)](e)
>   map(func, lst)
>   return t1, f1
> After rereading Guido's essay, I see that he says that you should only
> favor a built-in construct with an implied loop in situations where
> the function argument is also a python built-in, and not anything
> containing python code.  Now I don't claim to have any knowledge of
> the inner workings of the python interpreter, but I was wondering why
> this is the case?  I understand that a lambda needs to be interpreted
> where as C code doesn't, but what is it about that in combination with
> map that makes it slower then your for loop version?

If map is calling a builtin then you get one C function calling another. If
map is calling a Python function then it has to set up the Python calling
environment in full generality, negating at least some of the time saved by
using the implicit looping.

Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                 http://pydish.holdenweb.com/pwp/
Register for PyCon now!            http://www.python.org/pycon/reg.html

More information about the Python-list mailing list