[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()
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 easy.
Raymond
More information about the Python-Dev
mailing list