When Python's zip() stops early over iterators, what happens to items it already pulled?

## The mechanic `zip` produces its output one round at a time. Within a round it calls `next()` on each input in the order the arguments were written. If every call succeeds, it packs the results into a tuple and yields it. If any call raises `StopIteration`, `zip` stops the whole iteration immediately — and the values it already obtained from the inputs to the left in that unfinished round are simply dropped. They were never packed into a tuple, so nothing downstream ever sees them. Over lists this is a non-event. A list is an *iterable*, and zipping it creates a fresh iterator over it; the list itself is untouched and can be walked again from index zero. Over an *iterator* it is a real, observable side effect, because the iterator holds the position and `zip` has advanced it. ```python a = iter(range(4)) b = iter(range(2)) list(zip(a, b)) # [(0, 0), (1, 1)] next(a) # 3 — the value 2 was pulled and discarded ``` The first two rounds succeed. In the third, `zip` pulls `2` from `a`, then finds `b` exhausted, stops, and drops the `2`. Resuming `a` yields `3`. One record has vanished with no error. ## Where it bites in production The classic case is pairing two live streams. Imagine a payroll import where one reader yields employee identifiers and another yields the hours rows, both lazily from open files, and a loop zips them to build pay records. When the hours reader ends first, the identifier reader has already been advanced past the record it was about to pair. If the code then continues to use that identifier reader — for a reconciliation pass, a tail-handling branch, or a second zip — it starts one record late and never notices. The bug reads as an off-by-one in output that has no visible off-by-one in the code. The same mechanic explains a second surprise: partially consumed readers left mid-stream. A `zip` that stops early leaves both readers open and positioned somewhere in the middle. If those readers were not opened inside a `with` block, the loop ends but the resource does not — the file handle is left unclosed until the object is collected. Drive readers with a context manager so the handle closes on the normal exit, on an early `break`, and on the `ValueError` from `strict=True` alike. ## The idiom that depends on it The discard rule is not purely a hazard; one well-known idiom is built on it. Zipping the *same* iterator with itself groups consecutive items: ```python it = iter([1, 2, 3, 4, 5, 6]) list(zip(it, it)) # [(1, 2), (3, 4), (5, 6)] ``` Because both arguments name one shared iterator, the first `next()` in a round takes `1` and the second takes `2`. Generalise it with `zip(*[iter(seq)] * n)` for fixed-size chunks. Its documented weakness is exactly the discard rule: if the input length is not a multiple of `n`, the final partial chunk is pulled and thrown away rather than emitted. That is acceptable for fixed-width framing and quietly wrong for record batching, where you must not lose the tail. ## What strict=True does and does not fix `strict=True`, added in **Python 3.10**, changes the ending condition: on discovering that one input ended while another still had items, `zip` raises `ValueError` instead of stopping quietly. That converts a silent data loss into a loud failure, which is the right default for parallel data that must line up. What it does not do is restore the swallowed item. By the time the mismatch is detected, `next()` has already been called on the earlier inputs in that round, and there is no way to push a value back into a plain iterator. So `strict=True` tells you the inputs were ragged; it does not let you resume either input at the record boundary you wanted. If you need to keep the tail, `itertools.zip_longest` is the tool — it never abandons a round, padding the exhausted inputs with `fillvalue` instead. ## How to reason about it in review Three questions settle almost every case. Are the inputs iterators or re-iterable sequences? If sequences, the discard is unobservable and you can ignore it. Is any input used *again* after the zip? If yes, assume it has been advanced one item further than the last tuple you saw. Is losing the tail acceptable? If not, you want `zip_longest`, or you want to materialise the inputs before pairing them. And in every one of those cases, if the input is a reader over a real resource, it belongs in a `with` block so that stopping early still closes it.