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