Why does any() lose its short-circuit benefit when passed a list comprehension?

Python evaluates a function's arguments before the function runs. That single rule explains the whole difference between the two shapes: ```python any([check(x) for x in items]) # list built first, then any() runs any(check(x) for x in items) # generator handed over, any() pulls lazily ``` In the first line the list comprehension is a complete computation: it calls `check()` on every element of `items` and builds a `list` of that many booleans before `any()` is even entered. `any()` then does short-circuit — it looks at the first `True` in the list and returns — but the short-circuit saves nothing, because all the work it might have skipped has already happened. The cost is `n` predicate calls and `O(n)` memory, whatever the data looks like. In the second line the argument is a generator expression. Creating it does almost no work: it produces a generator object. `any()` then drives it with the iteration protocol, pulling one value at a time, and stops pulling at the first truthy result. If the first element already matches, `check()` ran exactly once and no list was created. The worst case (no match) is identical to the list version minus the allocation; the best and average cases can be dramatically cheaper. ### How big the difference is Three properties of the workload decide whether the difference is a curiosity or a bug: 1. **Predicate cost.** If `check()` is a comparison, `n` extra calls are noise. If it hashes a file, parses a payload, or crosses a network boundary, the list form multiplies that cost by the length of the input. 2. **Input size.** A three-element list is unmeasurable. A million-row cursor is not, and the list form also materialises a million-element result. 3. **Match position.** The lazy form's advantage is the distance from the start to the first decisive element. When matches are typically early, the lazy form is close to `O(1)`; when they are rare, the two converge. There is one thing the list form cannot do at all: a lazy source of unknown or unbounded length. `any(line.startswith("ERROR") for line in stream)` answers as soon as the first matching line arrives; the list version would first read the stream to its end, and over an endless source it never returns. ### The same trap in other shapes The defect is about eagerness, not about square brackets specifically. `any(tuple(...))`, `any(set(...))`, `any(list(map(check, items)))` and `any(sorted(...))` are all eager for the same reason — each builds a complete container before the call. Conversely `any(map(check, items))` and `any(filter(...))` are lazy in Python 3 and short-circuit exactly like a generator expression does. A subtlety worth knowing about generator expressions: only the outermost iterable is evaluated when the generator object is created; the rest of the pipeline runs on demand. So `any(check(x) for x in build_items())` calls `build_items()` immediately, and any laziness you wanted from `build_items` itself has to come from `build_items` being a generator too. ### When the list form is fine, and how to argue it in review Use the list form deliberately when you need the list for something else anyway — if you are about to report *which* items failed, you are not doing a short-circuiting existence check, you are doing a filter, and materialising is honest. Use it when the input is a small, already-materialised container and the predicate is a cheap attribute access; the readability of the two is identical and so is the runtime. Treat it as a defect when the predicate has any real cost or the input can grow. The review heuristic is simple: if the predicate calls anything you would put on a latency budget, the brackets are wrong. The fix costs two characters and never makes the code slower, which is why the lazy form is the sensible default even where the difference does not currently matter — inputs grow, predicates acquire I/O, and nobody revisits the brackets. All of this applies identically to `all()`, which stops at the first falsy element, and to `sum()`, `min()` and `max()` in the sense that they too accept a generator expression instead of a built container — although those must consume everything and so save only the allocation, not the predicate calls.