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

[Rodrigo Dias Arruda Senra]

[ 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):
 > > instead of "all"?
 >
 > Because "any" and "all" have shortcut semantics (they
 > return as soon as they can determine the final result).


[ Guido ]:
----------
 > See my blog:
 > http://www.artima.com/forums/flat.jsp?forum=106&thread=98196
 > 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