Why does `any(check(r) for r in rows)` stop early while `any([check(r) for r in rows])` does not?

### The mechanism is argument evaluation order, not the builtin Both spellings pass one object to `any()`. The difference is entirely in *when the predicate runs*. Python evaluates the arguments of a call before entering the function, so `any([check(r) for r in rows])` first executes the comprehension to completion, calling `check()` on every row and building a full list of booleans, and only then hands that list to `any()`. `any()` does short-circuit over the list - it stops scanning at the first `True` - but the expensive part is already done. The saving people imagine they are getting was spent before the call started. With `any(check(r) for r in rows)` the argument is a generator object, built without running the loop body at all. `any()` iterates it, and each `next()` triggers exactly one `check()` call. The moment one returns truthy, `any()` returns `True` and simply stops pulling; the generator is left suspended and then finalized, and no further predicate runs. `all()` is the mirror image: it stops at the first falsy value. This is the single clearest payoff of laziness, and it has nothing to do with memory. Even if the list of booleans were free to store, the eager form would still pay full price in CPU. ### When the short-circuit actually pays Three conditions have to hold together. The per-item work must be expensive relative to iteration overhead - a cheap comparison saves nothing measurable. The answer must usually be decidable early: if `any()` returns `False`, every item was examined regardless, and if `all()` returns `True`, likewise. And the order must be favourable or at least random; a predicate that only ever matches the last row gets no benefit at all, which is why deliberately ordering the cheap or most-likely-to-hit checks first is part of the technique. A nightly report generator makes the tradeoff concrete. Its validation stage asked 'is any row unparseable?' and the run took roughly 27 minutes, almost all of it inside the per-row check. Because a bad row, when there was one, was usually near the front of the batch, switching from the bracketed form to the bare generator expression made the failing runs finish in seconds - while the clean runs, which have to examine every row to answer `False`, stayed exactly as slow as before. That asymmetry is the honest way to describe the win: it improves the early-exit case and does nothing for the exhaustive one. ### What you give up, and what to watch The short-circuiting form throws away the individual results. If the report also needs to name *which* rows failed, `any()` over a generator expression is the wrong tool: iterate once, collect failures, and stop when you have hit whatever cap you care to report. Running `any()` first and then re-scanning to find the offenders is two passes over expensive work and, over a one-shot source, is not even possible. Side effects inside the predicate become order- and data-dependent. If `check()` writes a row status, increments a counter or logs, then with the lazy form those effects stop happening at an arbitrary point that depends on the data. Any code that assumed 'the predicate ran for every row' - a common way audit trails get holes - breaks the day someone drops the brackets. Keep predicates pure, and put the bookkeeping in an explicit loop where the stopping point is visible. The partially consumed generator is discarded when `any()` returns, so anything the source was going to do later - closing a resource, flushing a batch - does not happen at the moment you might expect. Manage those with an explicit context manager around the whole consumption rather than relying on the iteration reaching the end. ### The neighbouring idiom When you want not the boolean but the offending item, `next()` over a filtering generator expression is the natural form: `next((r for r in rows if not ok(r)), None)` scans only until the first failure and yields the row itself, with `None` as the default when everything passes. Note that the parentheses are mandatory there, because the default value is a second argument. This is the same early-exit machinery, and it usually replaces an `any()` call whose result would immediately be followed by a search for the culprit. A final measurement caution: for cheap predicates over small collections, the eager list version can be marginally faster, since iterating a list costs less per item than resuming a generator frame. The lazy form is not a blanket optimisation - it is a way to avoid work you have not yet proved you need, and it earns its keep only when that work is worth avoiding.