Why does sum() over a generator of booleans work as a match counter in Python?

The idiom rests on one fact about the object model: `bool` is a subclass of `int`. `True` is an `int` whose value is 1 and `False` is an `int` whose value is 0, so booleans participate in arithmetic like any other integer — `True + True` is `2`, and `sum([True, False, True])` is `2`. `sum()` needs nothing special to count; it is doing ordinary integer addition over values that happen to be 0 and 1. ### The two spellings ```python sum(pred(x) for x in items) # add the predicate's own True/False sum(1 for x in items if pred(x)) # add 1 per surviving element ``` Both are lazy and both allocate nothing beyond the generator object and the running total. The first requires the predicate to return an actual `bool` (or an int); if it returns a truthy *object* — a non-empty string, a list — the addition raises `TypeError` or, worse, adds something meaningful, so it is only safe when the predicate genuinely returns a boolean. The second is immune to that because it uses the standard truth test in the `if` clause and adds a literal `1`, which is why it is the safer default when the predicate is someone else's function. Both start from `0`, so an empty input counts to `0`. The eager alternative, `len([x for x in items if pred(x)])`, is correct and readable but builds a list solely to measure it — an allocation proportional to the number of matches, thrown away on the next line. On a small in-memory container that is fine; over a large or streamed source it is the same eagerness defect that spoils a reduction elsewhere. ### Why counting cannot short-circuit `any()` and `all()` can stop early because one element can settle the answer. A count has no such element: the total is only known once every candidate has been examined, so `sum()` necessarily consumes the whole iterable. This has two practical consequences. First, `sum()` over an unbounded source never returns — the lazy argument saves memory, not time. Second, when you only need to know *whether* something matched, counting everything and comparing to zero is strictly more work than asking `any()`; `if sum(...) > 0` is a common and needless pessimisation of `if any(...)`. There is one place the count genuinely beats the existence check even for a yes/no question: thresholds. "Are more than three items failing?" cannot be answered by `any()`, and short-circuiting can be recovered by hand — count in a loop and break once the threshold is crossed, or slice the source so the count is bounded. ### Related counting tools and their limits `sum()` counts one predicate. When you need several counts over the same pass, adding several generator expressions means several passes; a single explicit loop with several counters, or a `collections.Counter` keyed by the classification, is clearer and reads the source once — which matters when the source is a one-shot iterator that cannot be walked twice at all. `sum()` also takes a starting value as its second argument, so a running total can be seeded, and it refuses to concatenate strings on purpose — `str.join` is the tool there. Note also that `sum()` over booleans returns an `int`: `sum(flags) == 3` is a count, and if some caller expects a `bool` back, `bool(sum(flags))` (or better, `any(flags)`) is the explicit conversion. ### In review The idiom is idiomatic Python and worth recognising instantly when reading, but it deserves a moment's thought when writing. `sum(1 for x in items if pred(x))` states "count the matches" clearly. `sum(pred(x) for x in items)` is terser but couples correctness to the predicate's return type. And when the surrounding code only branches on whether the count is non-zero, the honest expression is `any()`, which says what is meant and stops early. The behaviour described here is stable across the Python 3 line and unchanged on 3.14. ### One more corner worth knowing Because `bool` subclasses `int`, booleans also work as indices and as multipliers: `["no", "yes"][flag]` and `count += flag` are both legal, and `sum()` is only the most useful member of that family. The relationship is one-directional — every `bool` is an `int`, but `isinstance(1, bool)` is `False`, so a function that must distinguish a genuine boolean from the integer 1 has to test `isinstance(value, bool)` before treating it as a number. That distinction rarely matters when counting and matters a great deal when serialising.