[Python-Dev] Efficient predicates for the standard library

[Raymond Hettinger]

> 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 loop at full C speed.  You cannot beat the ifilter()
version.


> 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
write
> efficient and well designed predicates with well-chosen names.  This
> discussion is the proof. :-)

Cut and paste is your friend. 

 

Raymond