[Python-Dev] Adding any() and all()

[Hugh Secker-Walker]

Hello Folks,

I've been lurking here for several months.  I've been using Python for
several years for prototyping fun.  And I'm one of the architects of
its extensive use in research, engineering development, and testing on
a large, commercial speech-recognition system.  I know a lot about
modeling mammalian auditory physiology.  And I have a relatively-large
collection of photos of Tim Peters.


> Raymond Hettinger:
> Will leave it open for discussion for a bit so that folks can voice
> any thoughts on the design.

Ignoring the important naming issues, I have two comments about the
any() and all() ideas:

1. I'm surprised that no one has suggested adding supporting unary
   methods to object, returning a boolean.  If __any__ and __all__
   existed, then containers that observed that their contents were
   immutable could rely on a single counter, self._numtrue, to
   implement the any and all operations in O(0) time via appropriate
   comparisons with __len__() (plus the amortized cost of maintaining
   self._numtrue).  Of course builtin containers could or will do this
   anyway.

2. In an offline discussion about using any() and all() a couple of us
   noticed their similarity to the containment operator 'in'.  Taking
   this idea as far as it can go in Python as we know it, you could
   introduce new keywords, 'any' and 'all', and corresponding byte
   codes dispatching to __any__ and __all__, giving the emminently
   readable usages:

       if any x:
           ...

       if not all y:
           ...

   This latter idea may be far-fetched.  But if there's any chance it
   would happen, it adds a twist to the naming issue.  Were this
   syntax introduced after any() and all() were available as builtins,
   simple use of 'any(blah)' would still work, but references to the
   no-longer-rare tokens 'any' and 'all', e.g. as functional objects,
   would, of course, no longer compile.

-Hugh