any(), all() and empty iterable

[Raymond Hettinger]

> The doc should speak to the intended audience: programmers, who like
> to make sure all bases and cases are covered.

FWIW, I wrote the docs.  The pure python forms were put in
as an integral part of the documentation.  The first
sentence of prose was not meant to stand alone.  It is a
lead-in to the code which makes explicit the short-circuiting
behavior and the behavior when the input is empty.

I will not change the sentence to "return false if any element
of the iterable is false."  The negations make the sentence
hard to parse mentally and do not provide a motivation for
the use of the word "all".  As it stands, the sentence provides
a clean lead-in for the code which is there "to make sure all
bases and cases are covered".  I put code in the docs to make
the docs precise.  We use code in the docs because it can
communicate clearly in cases where plain English prose is
either vague, awkward, hard to read, imprecise, or subject
to misinterpretation.

Of course, neither code nor accompanying prose help if prior
to reading them, a reader already has formed a strong but
incorrect mental picture of what the function does.  If
someone has a priori convinced themselves that all([]) returns
False or has never thought about that case, then a cursory
reading of the docs is unlikely to disabuse them of that notion.
At any rate, all readers of this thread now seem to be
dialed-in as to why the current behavior is desirable.

I will probably leave the lead-in sentence as-is but may
add another sentence specifically covering the case for
an empty iterable.


Raymond


P.S.  Now maybe we can start a new thread about why sum([])
returns zero ;-)