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 ! ::::
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4