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

Rodrigo Dias Arruda Senra rodsenra at gpr.com.br
Fri Mar 11 15:58:47 CET 2005

```[ Pierre Barbier de Reuille ]:
> They are called "sometrue" and "alltrue" ... IMHO, it explicits more
> what it means :
>
>   alltrue(i<5 for i in l)
>   sometrue(i<5 for i in l)
+1

[ from a comment in GvR's blog ]
> > Why not,
> > if True in (x > 42 for x in S):
> > instead of "any" and why not
> > if not False in (x > 42 for x in S):
>
> Because "any" and "all" have shortcut semantics (they
> return as soon as they can determine the final result).

[ Guido ]:
----------
> See my blog:
> Do we even need a PEP ?

In the absence of a PEP, soon will see in c.l.p discussions like:

"""
For completeness sake shouldn't there be a optimiztion
version for  nonetrue() ?

def nonetrue(S):
for x in S:
if x:
return False
return True

why not allfalse() ?
Due to the previous use of sometrue(), guess it becomes
easier to remeber nonetrue() than allfalse().

One may argue for aliasing(nonetrue, allfalse), and we are
back to _builtin pollution_.
"""

So, people might fallback to any() and all(),realising that:

'''not all()''' meaning somefalse()

'''not any()''' meaning nonetrue()==allfalse()

All I'm saying: +1 for the PEP.

OFF-TOPIC:

It is curious though that we choose to read an *implicit*
True in [all(), any()] instead of an implicit False.

I guess that is a moral or ethical choice coming from the Human
realm, favouring Truth instead of Falsity. But that difference
does not hold in the Boolean realm <wink>.

best regards,
Senra

--
Rodrigo Senra
MSc Computer Engineer     rodsenra at gpr.com.br
GPr Sistemas Ltda       http://www.gpr.com.br

```