Why does a Python generator expression produce nothing the second time you iterate it?

### One object, one pass A generator expression evaluates to a generator object, and a generator object is an *iterator*, not a re-iterable collection. The distinction matters exactly here. A `list` is an iterable: every `for` loop over it asks it for a brand-new iterator and starts from the front. A generator object is its own iterator - asking it for an iterator hands back the very same object, positioned wherever the last consumer left it. There is no rewind operation anywhere in the protocol. So the first full consumption runs the hidden loop to completion. When the source is exhausted the generator raises `StopIteration`, its frame is finished and released, and the object is permanently marked as done. Every later `next()` on it raises `StopIteration` again straight away. A `for` loop treats that as 'the sequence has ended', so it executes zero iterations, silently. `list()` on it returns `[]`. `sum()` returns `0`. `max()` raises `ValueError` for an empty sequence unless you passed `default`, which is often the only reason anyone notices. ### The bug this actually produces Consider a nightly report generator that streams parsed rows: ```python rows = (parse(line) for line in lines) count = sum(1 for _ in rows) total = sum(r.amount for r in rows) # always 0 ``` The count is right, the total is zero, and nothing failed. The report goes out with a real row count and no money in it. Because the failure is silent and only shows on the *second* aggregate, it survives code review easily - the two lines look symmetric, and each one is correct in isolation. The same trap appears whenever a generator expression is passed around: a helper that takes an iterable and loops over it twice works perfectly with a list argument and silently returns nonsense with a generator argument. That is why functions that iterate their input more than once should either document that they need a sequence or defensively materialize with `list()` at the top. ### The three fixes, and when each is right **Materialize once.** `rows = list(parse(line) for line in lines)` - or just use a list comprehension in the first place. Now both aggregates work and you can index and re-sort. The cost is memory proportional to the data, which is precisely what the generator expression was avoiding, so this is the right answer when the data comfortably fits. **Rebuild the expression.** Wrap it in a function or a small `lambda` and call it once per pass: each call evaluates the expression again and returns a fresh generator object over a fresh iteration of the source. Memory stays flat, but you pay for two passes over the source - fine over an in-memory list, wrong over a network stream or a file handle you have already consumed, and outright incorrect if the source itself is a one-shot iterator. **Single pass with two accumulators.** Loop once and update both figures inside the loop body. This is the only fix that works when the data is too large to hold *and* the source can only be read once. It is more code, and it is the answer an interviewer is usually fishing for in a data-pipeline context. ### Related traps worth naming Re-binding does not help. `a = (x for x in xs); b = a` gives two names for one generator object, so consuming through `a` empties it for `b`. Copying does not help either - a generator object cannot be copied or pickled. Partial consumption is sticky. `next(g)` inside a guard clause, or a `for` loop with a `break`, leaves the generator positioned mid-stream; the next consumer picks up from there rather than the beginning. That makes 'peek at the first item then process everything' a subtle off-by-one source unless you deliberately re-attach the peeked item. Sharing one generator object between threads is worse than a stale read. The object holds a single suspended frame, so concurrent consumers interleave items unpredictably - each item goes to exactly one thread, which is occasionally what people want and usually not - and CPython raises `ValueError` if a generator is re-entered while it is already running. If several workers must process the same values, materialize the data or give each worker its own expression; if they should split the work, put the items in a `queue.Queue` where the hand-off is explicit and thread-safe. Finally, exhaustion is not the same as emptiness. `list(g)` returning `[]` tells you nothing about whether the source was empty or whether someone upstream already drained it - which is exactly why the bug reads as 'no data today' rather than as an error.