[Python-Dev] Efficient predicates for the standard library

Alex Martelli aleaxit at yahoo.com
Mon Oct 6 03:17:16 EDT 2003


On Sunday 05 October 2003 11:57 am, 'Christian Stork' wrote:
> On Sat, Oct 04, 2003 at 09:24:48PM -0400, Raymond Hettinger wrote:
> ...
>
> > Your proposal is a net gain and I will change the docs as requested.
> > Having bool() as a default makes the functions more useful and less
> > error prone.  Also, it increases instructional value by giving an
> > example of a predicate (for who skipped class that day).  Also, your
> > proposed argument order matches common mathematical usage (i.e. All
> > elements in a <domain> such that <predicate> is true).
>
> Thanks, I agree.

Adding to this chorus of agreement, I'd also point out that the form
with seq first and pred second ALSO agrees with the usage in list
comprehensions of analogous semantics -- [x for x in seq if pred(x)] .


> > For your own purposes, consider using a faster implementation:
> >
> >     def Some(seq, pred=None):
> >         for x in ifilter(None, seq):

I suspect that what Raymond means here is ifilter(pred, seq) -- the
way he's written it, the pred argument would be ignored.

> >             return True
> >         return False
> >
> > All() and No() have similar fast implementations using ifilterfalse()
> > and reversing the return values.
>
> Interesting, this is almost exactly what my first attempt at this looked
> like.  Then I saw the examples in the doc and changed to the proposed
> ones.
>
> Honestly, I assumed that
>
>     x in iterable
>
> has a short-circuit implementation.  Why doesn't it?

It does.  But (assuming the occurrence of x is the Mth out of N items
in seq), "return True in imap(pred, seq)" must yield M times and perform
M comparisons, while "for x in ifilter(pred, seq): return True" -- while
still performing M comparisons, inside ifilter -- yields only once, so
it saves performing M-1 yields.  The second form is also more tolerant
in what it accepts (which is something of a golden rule...) -- it does
not malfunction quietly if pred returns true/false values that differ from
the "canonical" True and False instances of bool.  In some applications,
the resulting ability to use an existing pred function directly rather than
wrapping it into a bool(...) may further accelerate things.


Alex




More information about the Python-Dev mailing list