> 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 ;-) -- http://mail.python.org/mailman/listinfo/python-list