[Python-Dev] Efficient predicates for the standard library
cstork at ics.uci.edu
Sun Oct 5 05:57:27 EDT 2003
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.
> For your own purposes, consider using a faster implementation:
> def Some(seq, pred=None):
> for x in ifilter(None, seq):
> 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
Honestly, I assumed that
x in iterable
has a short-circuit implementation. Why doesn't it?
> > For enhanced assert support I'd advocate additional predicates for
> > easy and fast type checking, eg allListType, allIntType, etc.
> > Maybe all this should go into it's own `preds' module?
> Or maybe not ;-)
> Somewhere, Tim has a eloquent and pithy saying which roughly translates
> """Adding trivial functions is a net loss because the burden of learning
> or becoming aware of them (and their implementation nuances) will far
> exceed the microscopic benefit of saving a line or two that could be
> coded on the spot as needed."""
I hear you/him :-) and I'd be fine if you just change the docs. I
also agree that introducing predicates a la allInts seems like a bad
idea since it's overspecialisation. (I could think of better ways to do
type checking anyway.)
Let me just give you the reasons (in no particular order) for my
suggestion to include the `all' and `some/any' predicates:
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.
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.
1. & 2. encourage the use of asserts, which increases code quality.
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. :-)
> In this case, a single example in the docs may suffice:
> if False in imap(isinstance, seqn, repeat(int)):
> raise TypeError("All arguments must be of type int")
Just that this would be too much to type for me if I only wanted to
quickly (and without too much runtime overhead) check on myself. I'd
assert isinstance(seq, [int])
...but that doesn't exist yet. ...in Python, that is. ;-)
Anyway, thanks for the itertools package. I especially enjoy the parts
that remind me of Haskell!
Chris Stork <><><><><><><><><><><><><> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
More information about the Python-Dev