any(), all() and empty iterable

Steven D'Aprano steven at
Wed Apr 15 03:47:35 CEST 2009

On Tue, 14 Apr 2009 17:54:14 +0000, John O'Hagan wrote:

> Agreed; having absorbed the answers to my original question, I now
> understand why all('Robinson Crusoe' in books for books in []) - or with
> any object in place of the string, or indeed just all([]) - doesn't
> return False, but, vacuous truth notwithstanding (and it's apparently a
> not uncontroversial notion), it doesn't seem fair to return True without
> so much as a how's-your-father. ;)

I don't see why you call it unfair. It is very fair. You're just 
unfortunate that *your* use-case was one of the times that the alternate 
behaviour would be better, *and* you didn't know about vacuous truths. If 
you had known, you wouldn't have been surprised -- but that's true about 
everything. It is, in fact, a vacuous truth :)

I would be far more upset by all() raising an exception on an empty list! 
And it is very simple to create a version of all() which doesn't return 
true for vacuous truths.

def all2(sequence_or_iterator):
    """Like all() but returns False for vacuous truths."""
    # Untested
    it = iter(sequence_or_iterator)
         if not return False
    except StopIteration:
         return False
    return all(it)

> An exception, or at least a specific mention of the case of empty
> iterables in the docs (as Tim Chase suggested), would have baffled me
> less than my program telling me that the same items were both ubiquitous
> and entirely absent from a list of sets!
> Of course, it's possible people out there depend on the present
> behaviour.

You better believe it.


More information about the Python-list mailing list