How does itertools.zip_longest differ from the built-in zip on unequal-length inputs?

### The default is truncation, and it is silent The built-in `zip` walks its inputs in parallel and stops the moment any one of them is exhausted. `list(zip([1, 2, 3], ['a']))` is `[(1, 'a')]`. No exception, no warning, no log line — two of the three items simply never appear. That behaviour is right when truncation is the point (pairing an unbounded counter with a finite sequence, say), and wrong in the far more common case where the inputs were *supposed* to line up and a mismatch means something upstream is broken. ### zip_longest: pad instead of truncate `itertools.zip_longest(*iterables, fillvalue=None)` runs until the **longest** input is exhausted, substituting `fillvalue` wherever a shorter input has already run out. `list(itertools.zip_longest([1, 2, 3], ['a']))` gives `[(1, 'a'), (2, None), (3, None)]`. The number of tuples is the length of the longest input, and every tuple still has one element per input iterable, so downstream unpacking keeps working. Three details matter in practice. **The default fill is `None`.** That is fine until `None` is also a legitimate value in the data, at which point a padded slot and a real value become indistinguishable. The fix is a private sentinel: `MISSING = object()`, pass `fillvalue=MISSING`, and test with `is MISSING`. Since the sentinel cannot occur in real data, the test is exact. **One fill object is shared by every padded slot.** Passing a mutable object such as `[]` or `{}` as `fillvalue` puts the *same* object into every gap, so mutating one padded entry mutates all of them — the same aliasing trap as a mutable default argument. Fill with `None` or an immutable sentinel and construct a fresh object per row afterwards if you need one. **Padding hides the mismatch rather than reporting it.** zip_longest is the right answer when a short input is legitimate — an optional column, a series that starts later — and the wrong answer when a short input means a data defect, because it hands downstream code well-formed rows full of invented values. ### The third option: strict Python 3.10 (PEP 618) added the keyword-only `strict` parameter to the builtin: `zip(a, b, strict=True)` raises `ValueError` as soon as it discovers that one input is exhausted while another is not, naming which argument was shorter. On 3.14 all three behaviours are therefore available and each has a clear meaning: - `zip(a, b)` — stop at the shortest; truncation is intended. - `zip(a, b, strict=True)` — equal lengths are an invariant; a violation is a bug and should be loud. - `itertools.zip_longest(a, b, fillvalue=...)` — unequal lengths are expected and padding carries meaning. Most parallel iteration over data that *ought* to line up should be strict. It costs nothing, it fails at the point of the mismatch rather than three functions later, and the error message tells you which side was short. Because `strict=True` must confirm exhaustion before raising, the error surfaces when the iterators are consumed, not at call time — `zip` is lazy either way and returns an iterator, so nothing is checked until you actually iterate. ### Reading the output A subtle consequence of padding is that the *number of rows* now reflects the longest input, which is rarely what a length check downstream expects. Code that reports "processed N records" from `len(list(zip_longest(...)))` is counting real rows plus padded ones. Where that matters, count before combining, or filter the padded rows out explicitly with the sentinel test. ### Answering it well State the one-line difference first — shortest-wins versus longest-with-padding — then name `fillvalue` and its `None` default, then show that you know the third option exists and when each is appropriate. Mentioning the shared-fill-object trap and the sentinel technique for distinguishing padding from a genuine `None` turns a screening answer into a convincing one.