A triage bot peeks with `head, *rest = fetch_tickets()`, yet every ticket's side effect fires at once and again later — why?

### Why the assignment drains the stream `head, *rest = fetch_tickets()` is extended iterable unpacking. To bind `rest`, the interpreter must know how many values are left after the fixed targets are satisfied, and the only way to learn that from an arbitrary iterable is to pull items until it stops. So the assignment iterates the generator to exhaustion and builds a list of everything after the first item. Three consequences follow, and a senior answer names all three: - **Laziness is gone.** The generator was presumably written to stream, so that the bot processes tickets as they arrive. The unpacking line collapses that into one blocking pass. - **Memory is unbounded.** `rest` is a real list holding every remaining item. On a backlog burst it is the whole backlog, resident. - **Side effects fire early and all at once.** If the producer marks each ticket as seen, emits a metric, or writes an audit row as it yields, all of those happen at the assignment, not as each ticket is handled. If the process dies mid-triage, every ticket is already marked but none is triaged. Even the un-starred form consumes more than it looks. `a, b = some_generator()` pulls a *third* item before it can decide the stream was too long, so the side effect for item three has already run when the `ValueError: too many values to unpack (expected 2)` is raised. ### Why the effect then happens twice A generator function returns a fresh generator object each time it is called, and each generator object is single-use: once exhausted it yields nothing further. So code that "peeks" with `head, *rest = fetch_tickets()` and later iterates `for ticket in fetch_tickets():` has called the function twice and produced two independent runs of the same sequence — with the per-item side effect executed twice per ticket. Nothing errors; the duplication is silent, which is why it survives review. The near-miss variant is worse: reusing the *same* exhausted generator object for the second pass produces zero iterations, so the loop body silently never runs. One spelling duplicates work, the other skips it, and both look correct on the page. ### Diagnosing it The symptom is duplicated per-item effects with no exception — double audit rows, a metric counting twice, a webhook delivered twice. Confirm it by counting production, not consumption: wrap the producer in a counter, or assert in a test that a fake source is iterated exactly once. That test must be fast enough to run constantly; if the only coverage lives in a 27-minute suite nobody runs before pushing, the defect reaches production, and duplicated side effects are exactly the class of bug that a slow suite is too late to catch. A focused unit test with a hand-rolled counting iterable runs in milliseconds and pins the contract. ### Fixing it **Keep one iterator and pull from it.** The direct replacement for peeking is `next`: ```python it = fetch_tickets() head = next(it) # or next(it, None) for a safe empty case for ticket in it: # the same iterator, resumed where it stopped triage(ticket) ``` The generator is advanced exactly once for the head and then continues; nothing is materialised and each side effect happens once, at the moment its ticket is handled. **Take a bounded window with `itertools.islice`** when you want the first N without draining the rest. `list(islice(it, 10))` gives ten items and leaves the iterator positioned for the rest. **Use `itertools.tee` only when two genuine passes are needed**, and remember what it costs: it buffers every item the slower consumer has not yet reached, so if one branch runs far ahead the buffer grows to the gap. `tee` trades duplicate *production* for memory; it is right when re-running the producer would repeat side effects, wrong when the sequence is huge and the consumers move at different speeds. **Or remove the reason to care.** The deepest fix is that a producer should not carry the side effect at all. If `fetch_tickets` only yields tickets and the "mark as seen" write lives in the consumer, then consuming it twice is merely wasteful rather than wrong, and unpacking it is a memory question instead of a correctness one. Side effects buried in a generator make every consumption pattern a hazard, and callers cannot see them. **Guard the boundary.** Where a function must return something safely re-iterable, return a concrete sequence and say so in the signature and the docstring, rather than handing back a generator that the caller will unpack and re-call.