any(), all() and empty iterable

[Raymond Hettinger]

> Thanks for weighing in, Raymond.

You're welcome.

> As long as people are getting in their
> last licks on this one ...
>
> Including the word "all" in the definition of "all()" is suboptimal.
> Especially since the everyday meaning of "all" is ambiguous. Sure, leave
> in the code-equivalent to clarify things, but why not clarify in text,
> also? Here's a compromise:

No thanks.  The word "all" is in the text for a reason.  It provides
the motivation and mental context for the naming of the function.
The code is there to make the notion precise and it does its job fine.
I've already made a doc update to cover the case for an empty
iterable.

This is a simple function.  Too much word-smithing actually makes it
harder to understand for normal users.  Besides, nothing will truly
satisfy newsgroupies hell-bent on misreading the docs.

The more interesting challenges have been aimed at improving the
understandability of super(), str.split(), and itertools.groupby().
The toughest challenge so far has been to document descriptors in a
comprehensive and precise way:

    http://users.rcn.com/python/download/Descriptor.htm


Raymond