Introduction

any() and all() are built-in Python functions for aggregating truth values across an iterable. They are compact, short-circuiting, and ideal for validation, filtering gates, and guard conditions, but they only make sense if you are clear on Python truthiness and on the surprising behavior of empty iterables.

What any() Does

any(iterable) returns True if at least one element is truthy:

print(any([0, "", None, 5]))
print(any([False, 0, ""]))

Output:

True
False

It stops as soon as it finds the first truthy value. That short-circuit behavior matters for both performance and side effects.

What all() Does

all(iterable) returns True only if every element is truthy:

print(all([1, True, "x"]))
print(all([1, 0, 3]))

Output:

True
False

It stops at the first falsy value.

Empty Iterable Behavior

This is the part that surprises people most:

print(any([]))
print(all([]))

Output:

False
True

any([]) is False because there is no truthy element.

all([]) is True because there is no violating element. This is called vacuous truth. It is mathematically consistent, but you should still think carefully about whether it matches your business rule.

If you need "non-empty and all pass," write that explicitly:

def non_empty_all(items):
    return bool(items) and all(items)

Use Generator Expressions for Real Predicates

Most useful code combines any() or all() with a condition:

1users = [
2    {"id": 1, "active": True},
3    {"id": 2, "active": False},
4    {"id": 3, "active": True},
5]
6
7has_inactive = any(not u["active"] for u in users)
8all_have_id = all("id" in u for u in users)
9
10print(has_inactive)
11print(all_have_id)

This is usually better than writing a manual loop when the logic is a simple existence or universal check.

Prefer Generators Over List Comprehensions

A generator expression is usually the right shape:

all_valid = all(x > 0 for x in [1, 2, 3])

This is usually better than:

all_valid = all([x > 0 for x in [1, 2, 3]])

The generator version avoids creating an unnecessary list and preserves short-circuit behavior more naturally.

Truthiness Rules Matter

any() and all() do not require explicit booleans. They use Python truthiness. Values commonly treated as falsy include:

• 'False'
• '0'
• '0.0'
• '""'
• '[]'
• '{}'
• 'None'

That means this can be misleading if zero is valid data:

scores = [0, 1, 2]
print(all(scores))

Output:

False

If the real condition is "not None," write that explicitly:

scores = [0, 1, 2]
print(all(score is not None for score in scores))

Short-Circuiting Can Affect Side Effects

Because both functions stop early, side-effect-heavy expressions can behave in surprising ways. For example:

1def check(x):
2    print("checking", x)
3    return x > 0
4
5print(all(check(x) for x in [1, 2, 0, 4]))

Once 0 fails the predicate, the remaining element is never checked.

That is usually a feature, but if you need to inspect every failure, you should collect the failures explicitly rather than relying on all().

A Readability Rule

any() and all() make code more declarative when the predicate is simple:

• "is there any failing item"
• "do all records satisfy this rule"

If the predicate becomes long and tangled, extract it into a named helper function. That keeps the expression readable while preserving the concise API.

Common Pitfalls

• Forgetting that all([]) returns True and any([]) returns False.
• Treating 0 or "" as invalid accidentally because they are falsy.
• Using list comprehensions when generator expressions are enough.
• Relying on side effects inside the predicate and forgetting that short-circuiting stops early.
• Writing one very dense nested any() or all() expression that nobody can read later.

Summary

• 'any() returns True if at least one element is truthy.'
• 'all() returns True only if every element is truthy.'
• Both short-circuit, which helps efficiency.
• Empty iterable behavior is different for each function and often surprises people.
• Use generator expressions and explicit predicates when truthiness alone is not the real rule.