It follows from exactly the same logic. The following are theorems, at least as long as x and y are lists of Booleans:
all(x + [True]) == all(x)
any(x + [False]) == any(x)
all(x + y) == (all(x) and all(y))
any(x + y) == (any(x) or any(y))
not all(x) == any(not xi for xi in x)
not any(x) == all(not xi for xi in x)
Any other values for all([]) and any([]) would cause some or all of these theorems to be correct for all values of x and y except the empty list. In practice this would mean you would have a bug in your program on most occasions where the argument of one of these functions was empty, unless you included a special case for empty sequences.
For example, suppose you're processing a request that includes some tasks and some attachments. You might write something like this:
if any(task.is_failed() for task in request.tasks):
raise TaskFailed(request)
if any(x.is_too_large() for x in request.attachments):
raise AttachmentTooLarge(request)
Clearly for this code to do the right thing in the case where a request has tasks or attachments but not both, we need any([]) to be false. And the corresponding requirement applies to all([]) if our task interface is a little different:
if not all(task.is_succeeded() for task in request.tasks):
raise TaskFailed(request)
Now, there are occasionally programs where you do need a special case for empty sequences; for example, if you have three search results, you might want to return a page containing just those results, but if you have zero, you probably don't want to just return an empty page — the user might think the software is just broken. And in the above example, if there are neither any tasks nor any attachments, it might or might not be useful to report that the user accidentally submitted an empty request. But it is unusual for such a special case to just fall out of a possible alternative semantics of all() and any().
For example, suppose you're processing a request that includes some tasks and some attachments. You might write something like this:
Clearly for this code to do the right thing in the case where a request has tasks or attachments but not both, we need any([]) to be false. And the corresponding requirement applies to all([]) if our task interface is a little different: Now, there are occasionally programs where you do need a special case for empty sequences; for example, if you have three search results, you might want to return a page containing just those results, but if you have zero, you probably don't want to just return an empty page — the user might think the software is just broken. And in the above example, if there are neither any tasks nor any attachments, it might or might not be useful to report that the user accidentally submitted an empty request. But it is unusual for such a special case to just fall out of a possible alternative semantics of all() and any().