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

Jack Diederich jack at performancedrivers.com
Fri Mar 11 04:58:22 CET 2005

On Thu, Mar 10, 2005 at 10:22:45PM -0500, Raymond Hettinger wrote:
> [Bill Janssen]
> > I think I'd want them to be:
> > 
> > def any(S):
> >   for x in S:
> >     if x:
> >       return x
> >   return S[-1]
> > 
> > def all(S):
> >   for x in S:
> >     if not x:
> >       return x
> >   return S[-1]
> > 
> > Or perhaps these should be called "first" and "last".
> -1
> Over time, I've gotten feedback about these and other itertools recipes.
> No one has objected to the True/False return values in those recipes or
> in Guido's version.  
> Guido's version matches the normal expectation of any/all being a
> predicate.  Also, it avoids the kind of errors/confusion that people
> currently experience with Python's unique implementation of "and" and
> "or".
> Returning the last element is not evil; it's just weird, unexpected, and
> non-obvious.  Resist the urge to get tricky with this one.  

Perl returns the last true/false value as well, and it is a subtle trap.
I worked at a perl shop that had a long style guide which outlawed using
that side effect but people did anyway.  I'm +1 on having it return a
true boolean for the same reason "if (x = calc_foo()):" isn't supported,
if there is a quirky side effect available someone will use it and someone
else won't notice.
[in fact we had a guy who was "downsized" for doing things like calling
database queries on the return value of a function that was documented
as returning True/False]

Perl shops require long style guides becuase perl is, ummm, perl. Python
is a boon because YAGN (a style guide).  The fewer side effects the better.


More information about the Python-Dev mailing list