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

M.-A. Lemburg mal at egenix.com
Sat Mar 12 01:32:31 CET 2005


Guido van Rossum wrote:
> Here's my take on the key issues brought up:
> 
> Alternative names anytrue(), alltrue(): before I posted to my blog I
> played with these names (actually anyTrue(), allTrue(), anyFalse(),
> allFalse()). But I realized (1) any() and all() read much better in
> their natural context (an if statement), and there's no confusion
> there; (2) anyFalse() and allFalse() are redundant, so there's no need
> to distinguish between anyTrue() and anyFalse(). (To the person who
> wondered why we default to True: because 'if' tests for True, duh. :-)

I've been using exists() and forall() in mxTools for years.
The names originate from math usage, where you often
use these qualifiers.

A note on builtins: Most tools in mxTools automatically
get registered as builtins when you load the module. The
motivation for this was that wanted to have easy access
to these often used APIs.

However, a few years down the line I realized that this
kind of usage just causes confusion when you read code:

* it is not clear where the APIs originate

* the code dependencies are not longer easily visible

Ever since, I've switched to making all use of these
functions explicit with reference to the mx.Tools
module.

     http://www.egenix.com/files/python/mxTools.html

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 12 2005)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::


More information about the Python-Dev mailing list