[knappa]

I would read all more formally as: for each element in this list, the element is true. Then you get a vacuous truth. (Think about the negation: there is an element in the list which is false. That's obviously false.)

Any would be more formally: there is an element of the list which is true. But the list doesn't have any elements, so that's false.

Looks logical to me. Plus you get that `not any( map(lambda x: not x, l) )` is the same as `all(l)` for any list `l`.

[rightbyte]

> Any would be more formally: there is an element of the list which is true. But the list doesn't have any elements, so that's false.

It is just a matter of convention and I see no logic behind why any convention would be worse or wrong. But I believe if 'any' implies 'at least one' so should 'all' otherwise they use different conventions.

In practice I get it was arbitrary choices and this is just how you end up when doing the obvious implementation.

   def all(l):
      for e in l:
         if not e:
            return False
      return True

   def any(l):
      for e in l:
         if e:
            return True
      return False

[dragonwriter]

> But I believe if 'any' implies 'at least one' so should 'all' otherwise they use different conventions.

The conventions they use are not an arbitrary choice, and are those of predicate logic. any() is the “for any” (existential quantification) operator, while all() is the “for all” (universal quantification) operator.

They are deeply connected: “all items in xs are true” is “there are not any items in xs that are not true”, or, in code terms, all(xs) == not any(not x for x in xs).

And, vice versa, any(xs) == not all(not x for x in xs)

[rightbyte]

Sure thinking about it the 'all ([]) => True', 'any ([]) => False' might be more intuitive.