[Python-Dev] Efficient predicates for the standard library

Raymond Hettinger python at rcn.com
Sun Oct 5 11:46:29 EDT 2003

> Honestly, I assumed that 
>    x in iterable
> has a short-circuit implementation.  Why doesn't it?

It does.

The ifilter() version is faster only because it doesn't have to
continually return values to the 'in' iterator.  The speedup is a small
constant factor.

> Let me just give you the reasons (in no particular order) for my
> suggestion to include the `all' and `some/any' predicates:
> 1. Efficiency
> Maybe I'm a bit naive here, but it seems to me that since these
> predicates involve tight inner loops they offer good potential for
> speedup, especially when used often and over many iterations.

You're guessing incorrectly.  The pure python versions use underlying
itertools which run at full C speed.  You cannot beat the ifilter()

> 2. Readabilty
> If we offer universally-used predicates with succinct names which are
> available as part of the "batteries included" then that increases 
> readabilty of code a lot.

I put the code in the docs in a form so that people can cut and paste
the function definitions it as needed.  Then, they can use all(), any(),
or no() to their heart's content.  

> 4. It's *not* trivial!
> Contrary to what you imply it's not trivial for everybody to just
> efficient and well designed predicates with well-chosen names.  This
> discussion is the proof. :-)

Cut and paste is easy. 



More information about the Python-Dev mailing list