In the comprehension [y for x in xs for y in f(x)], how many times is f called?

## The mechanic Multiple `for` clauses transliterate to nested `for` statements in written order, so: ```python [y for x in xs for y in f(x)] ``` is: ```python result = [] for x in xs: for y in f(x): # header of the inner loop result.append(y) ``` A `for` statement evaluates its iterable expression once, when that statement is reached. The inner statement is reached once per outer iteration, so `f(x)` is evaluated once per item in `xs`. The leftmost iterable, by contrast, sits in the outer header and is evaluated exactly once for the whole comprehension. So the answer is: `len(xs)` calls if `xs` is a sized collection; one call per item produced if `xs` is a generator; and **zero** calls if `xs` is empty, since the inner statement is never reached. ## Why the language wants it this way Re-evaluation is what makes dependent clauses possible, and dependent clauses are half of why multi-clause comprehensions exist at all. Names bound by a clause are visible to every clause to its right, to the `if` clauses after them, and to the output expression. That gives the whole family of triangular and ragged iterations: ```python [(i, j) for i in range(4) for j in range(i + 1, 4)] # [(0, 1), (0, 2), (0, 3), (1, 2), (1, 3), (2, 3)] ``` Each `range(i + 1, 4)` is a fresh range object built from the current `i`. If the inner iterable were evaluated once up front, this could not work at all — the language would have to choose some value of `i` before the loop began, and there is none. The visibility rule runs one way only. A clause cannot see names bound to its right, which is why swapping the two clauses in the example above fails, and why the order of clauses is not a free choice once a dependency exists. ## The cost this hides Because the re-evaluation is invisible in the one-line form, a comprehension is an easy place to accidentally multiply work. Three shapes come up repeatedly. **The independent inner call.** `[y for x in xs for y in expensive()]` calls `expensive()` once per item even though the result never varies. Hoist it: bind it to a name before the comprehension and iterate that name. Note the shape change this implies — if `expensive()` returns an *iterator* rather than a re-iterable collection, hoisting is not merely an optimization, it changes the result, because the iterator is exhausted after the first outer pass and every later pass sees nothing. **The dependent but repeated call.** `f(x)` where the same `x` recurs. No hoisting is possible, but `functools.lru_cache` or `functools.cache` on `f`, or a plain dict built before the loop, removes the duplicate work. **The quietly quadratic inner iterable.** An inner clause that scans a list to filter it — searching a list once per outer item — is a nested scan wearing a comprehension's clothes. Build a `set` or `dict` before the comprehension and let the inner clause be a lookup. ## What CPython will and will not do for you It will not hoist the call. `f` may have side effects, may be rebound between iterations, and may return something different each time, so re-evaluating it is required by the semantics, not merely permitted. The specializing interpreter can make each call cheaper; it cannot turn N calls into one. Profile-driven reasoning applies here: if a comprehension is hot, the first thing to check is not the loop overhead but whether its inner clause is doing work that could have been done once. ## Answering it well Give the count, then the rewrite that proves it, then the two consequences: this is what enables a dependent inner iterable, and it is what makes an expensive inner expression an N-times cost. Mentioning that the leftmost iterable is evaluated once while every later one is re-evaluated shows you know the asymmetry rather than having memorised one half of it.