Why does Python's zip() stop at the shortest input, and how do you catch ragged data?

## The stopping rule `zip(*iterables)` returns an iterator. Each step pulls one item from every input, left to right, and yields them as a tuple. The moment any input signals exhaustion, `zip` stops. It does not raise, does not pad, does not warn — the output simply ends. Zip over a three-element list and a two-element list produces two tuples. That is a deliberate design choice, not an oversight. `zip` accepts arbitrary iterables, including generators, open files and infinite sequences. It cannot ask them how long they are, because most iterables have no length and asking would mean consuming them. Stopping at the shortest is also what makes the pairing of a finite sequence with an unbounded counter useful at all. ## Why silent truncation is a real defect class The cost of that rule is that a data bug becomes invisible. Consider importing a payroll CSV: one pass builds a list of 83 employee identifiers, another builds the list of hours worked, and a `zip` marries them for the pay run. If a filter drops one hours row — a blank line, a header counted twice, a row rejected by validation — the identifiers list is 83 long and the hours list is 82. `zip` yields 82 pairs and the last employee vanishes from the run. Nothing raises. The output is well-formed, plausible, and wrong. Worse, if the two lists have drifted *out of alignment* rather than merely differing in length, every pair after the drift point is mismatched: the right shape, entirely wrong data. Truncation at least loses the tail; misalignment corrupts everything downstream of it. ## strict=True — Python 3.10 PEP 618 added the keyword-only `strict` parameter in **Python 3.10**: `zip(a, b, strict=True)`. It changes only the ending condition. While every input still has items, behaviour is identical. When one input is exhausted, `zip` checks whether the others are exhausted too; if any is not, it raises `ValueError` with a message naming which argument was longer or shorter. It is keyword-only, so it can never be mistaken for another iterable, and it defaults to `False` so existing code is unaffected. Two properties are worth naming in an interview. First, the check is **lazy**: nothing is validated at call time, because building the iterator consumes nothing. The `ValueError` surfaces only when the consumer reaches the end of the shortest input — so a `zip(..., strict=True)` that is never iterated, or is abandoned early by a `break`, never raises at all. Second, because the error arrives at the end, any work you performed per-tuple has already happened. If the loop body was writing pay rows, those rows are written by the time the mismatch is detected. Where partial output is unacceptable, either materialise the pairs first (`rows = list(zip(a, b, strict=True))`) and only then act on them, or wrap the whole write in a transaction you can roll back. That is exactly the judgement an interviewer is listening for. ## zip_longest — when ragged is legitimate Sometimes the inputs genuinely differ in length and dropping the tail is wrong. `itertools.zip_longest(*iterables, fillvalue=None)` runs until the **longest** input is exhausted, substituting `fillvalue` for every input that has already ended. With `fillvalue=0.0` the missing hours become zero rather than disappearing; with the default `None` you can test for the sentinel and branch. Pick the fill value with care: it lands in your data. A numeric default of `0.0` in a payroll import quietly asserts that the employee worked no hours, which may be a more expensive lie than dropping the row. `None` forces the consumer to make that decision explicitly, which is usually what you want. Note also that `strict` and `zip_longest` are mutually exclusive by nature — one demands equal lengths, the other assumes unequal ones — so the choice is a statement about your data contract. ## What not to do instead The reflex fix is to compare lengths before zipping: `if len(a) != len(b): raise`. That works for lists and fails for everything else, because `len()` does not exist on generators, file objects or database cursors, and materialising a stream just to measure it defeats the reason it was streamed. `strict=True` performs the same check without needing a length, which is precisely why it was added rather than left to callers. ## The decision, stated once Default to `strict=True` whenever the inputs are supposed to line up — parallel columns, keys and values, records and their computed results. Reach for `zip_longest` only when raggedness is part of the contract, and then choose the fill value on purpose. Leave bare `zip` for the case where truncation is the intent, such as pairing a finite sequence against an unbounded source.