Home Original page

Splitting lists

Steve Holden sholden at holdenweb.com
Fri Feb 28 07:35:46 EST 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.

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