Why can a list be looped over repeatedly while a generator object is exhausted after one pass?

### The rule in one sentence `for x in xs` always calls `iter(xs)` first. Whether the loop can be repeated depends entirely on what that call returns: a **fresh cursor** (re-iterable) or **the same cursor you already drained** (one-shot). ### Containers hand out new cursors A list stores its elements. Its `__iter__` builds a new iterator object each time it is called, and each of those iterators carries its own position, starting at index 0. That is why two nested loops over the same list do not interfere, why `sum(xs)` followed by `for x in xs` both see the full contents, and why you can pass the same list to five different functions without anything being consumed. The elements are the list's state; the position is the cursor's state, and cursors are disposable. The same is true of a tuple, a `str`, a `set`, a `range` object and a `dict` view. A `dict` view is a particularly clean demonstration: the view is re-iterable and stays a live window on the dictionary, while an iterator taken *from* the view is single-use. ### A generator object is already the cursor Calling a generator function does not run its body; it returns a **generator object**, which is an iterator. Its `__iter__` returns `self`, because there is nothing else it could return — the "position" is a suspended stack frame, and there is only one of them. Consuming it advances that frame to the end. A second `for` loop over the same name calls `iter()`, gets that same finished object back, immediately sees end-of-iteration, and runs the body zero times. Nothing raises. That is the important half of the answer: an exhausted iterator does not complain, it simply reports that it is done, which is exactly what an *empty* source reports. The protocol has no way to express "already consumed", so the failure surfaces as a silently wrong result rather than a traceback. ```python def timestamps(): yield 100 yield 90 stream = timestamps() print(sum(stream), sum(stream)) # 190 0 ``` ### What it looks like in production Consider a search-index rebuilder that reads documents from a lazy source. The first pass computes the newest timestamp in the batch so the job can detect a clock-skew artefact — a machine whose clock ran ahead, stamping documents into the future and poisoning recency ranking. The second pass then filters the documents against that threshold and writes them into the index. If the source is a generator object bound to one name, the second pass reads an exhausted cursor: zero documents are filtered, zero are written, and the rebuild "succeeds" against an empty batch. Worse, the symptom is masked downstream — the query tier is still serving an 83% cache-hit rate, so most user traffic never touches the newly-empty index, and the incident surfaces days later as slowly degrading results rather than as an alert. The two properties that make this bug expensive are exactly the two the protocol guarantees: laziness and silence. ### The fixes, and when each is right - **Materialize once**: `rows = list(source)`, then loop over `rows` as often as you like. Simplest and fastest for repeated full passes; the cost is holding the whole batch in memory, so it needs a stream you know is bounded. - **Call the generator function again**: `for r in documents(): ...` twice creates two fresh generator objects. Bounded memory, but the body re-runs — re-reading a file, re-issuing a query, or re-consuming an upstream iterator — so it costs the work twice and can observe different data on the second run. - **Make the source re-iterable**: an object whose `__iter__` builds and returns a *new* generator each time it is called behaves like a container to every caller, without materializing anything. - **Restart the underlying resource**: a file object is an iterator, but the file it wraps is seekable, so calling its `seek` method with 0 rewinds it for another pass. ### How to spot it in review Look for a name bound to a lazy object that is *read more than once*: a length or a `sum()` before the real loop, a debug log line that walks the stream, a validation pass, a conditional that peeks. Any of those turns the real pass into an empty one. When you have the object in hand, `iter(x) is x` answers the question directly — `True` means you are holding a one-shot cursor, not a container. And when you are the one designing the function, be explicit about which you return: a documented lazy contract is fine, an accidental one is a defect factory.