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

[Guido van Rossum]

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. :-)

Whether to always return True and False or the first faling / passing
element? I played with that too before blogging, and realized that the
end case (if the sequence is empty or if all elements fail the test)
can never be made to work satisfactory: picking None feels weird if
the argument is an iterable of bools, and picking False feels weird if
the argument is an iterable of non-bool objects.

Whether to use each() and some() instead of all() and any(), to
preserve variable namespace: each() in particular (and some() to some
extent) emphasizes the individual element, while all() emphasizes the
whole set. As long as we accept that the return value should not
return one of the arguments elements, I prefer emphasizing the group.
The namespace argument doesn't weigh much in my mind; there's no
backwards incompatibility, and there are plenty of builtins that are
routinely reused as variables (e.g. str, file, id, type) without
apparently affecting readability. Context helps a lot!

Whether to segregate these into a separate module: they are really a
very small amount of syntactic sugat, and I expect that in most cases,
instead of importing that module (which totally makes me lose my
context while editing) I would probably just write the extra line that
it takes to get the same effect with an explicit for loop and if
statement.

What worries me a bit about doing a PEP for this simple proposal is
that it might accidentally have the wrong outcome: a compromise that
can carry a majority rather than the "right" solution because nobody
could "sell" it. Yet, if people really feel strongly that there are
more issues that need to be discussed, and they think it's worth their
time, let someone stand up now to own the PEP and guide the
discussion. But personally, I think it's more efficient if Raymond
just checks in his code now. :-)

BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code. The PEP, in addition to making a really strong case for each of
the removals, will have to deal with a deprecation period, possibly
moving the functions to a "functional programming" module, etc.

PS in the blog responses, a problem with sum() was pointed out --
unless you use the second argument, it will only work for numbers. Now
that string concatenation is apparently O(N) rather than O(N**2) (is
that right, Raymond?) maybe this could be revised.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)