How does Python's map() behave when given several iterables of different lengths?

### The n-ary form of map The signature people remember is `map(function, iterable)`, but the real one is `map(function, *iterables)`. Given more than one iterable, `map` advances a cursor over each of them in lockstep and calls the function once per step with one argument taken from each: ```python list(map(lambda a, b: a + b, [1, 2, 3], [10, 20, 30])) # [11, 22, 33] ``` This is the element-wise combine that people otherwise write as a comprehension over `zip()`. In fact `map(f, a, b)` and `(f(x, y) for x, y in zip(a, b))` produce the same values. ### The arity rule The number of iterables fixes the number of arguments the callable receives. Pass two iterables to a one-parameter function and Python raises `TypeError: <lambda>() takes 1 positional argument but 2 were given`. Crucially that error appears **when the first item is consumed**, not when `map(...)` is evaluated, because `map` does not call the function during construction. A `map` built with the wrong arity looks perfectly healthy until something iterates it. The mirror mistake is passing a function that needs two arguments and a single iterable of pairs. `map(f, [(1, 2), (3, 4)])` calls `f((1, 2))` - one tuple argument, not two - and fails. Unpacking pre-zipped tuples needs either a wrapper that does the unpacking, or the dedicated stdlib combinator for that shape. ### Truncation to the shortest input Iteration ends the moment any one input raises `StopIteration`. There is no padding and no error: ```python list(map(pow, [2, 3, 4], [3, 2])) # [8, 9] ``` `pow(2, 3)` is `8`, `pow(3, 2)` is `9`, and the `4` is never used because the second list ran dry. That silence is a genuine hazard when the two sequences are supposed to be parallel records - a header row list and a values list, say - and one of them lost an element upstream. The result is quietly short rather than loudly wrong. **Note the deliberate contrast with `zip()`.** Python 3.10 added `strict=True` to `zip()` (PEP 618) precisely so that mismatched parallel sequences raise `ValueError` instead of truncating. `map()` received no equivalent, and still has none on 3.14. If strictness matters, the practical route is `map(func, *zip(*pairs))`-style restructuring, or more simply a comprehension over `zip(a, b, strict=True)`, which gets you both the strictness and the readability. Python 2's `map` had the opposite behaviour again: it padded the shorter inputs with `None` and returned a list as long as the longest input. Anyone carrying that memory across will read modern truncation as a bug. ### Consuming side effects on partially-read inputs Because `map` pulls one item from each source per step, the longer sources are left partially consumed if they are themselves iterators rather than lists. After the map is exhausted, an input iterator may have had one extra item pulled from it - the pull that produced the value discarded when a sibling ran out. If those inputs are file handles or generators you intend to keep reading, that lost item is a real defect. With plain lists it does not arise, since a list can be re-iterated from the start. ### Where the multi-iterable form is genuinely worth it It reads well when the callable is an existing named function and the intent is "combine these two parallel sequences element by element": merging a list of keys with a list of values, applying a per-record formatter, or comparing two runs field by field. The moment you find yourself writing `map(lambda a, b: ...)`, a comprehension over `zip(a, b)` names both elements and is easier to read - and with `strict=True` it also catches the length mismatch. ### The filter contrast `filter` has no n-ary form at all. Its signature is `filter(function_or_None, iterable)` - exactly one predicate and exactly one iterable - and passing a second iterable raises `TypeError`. Filtering pairs of parallel sequences therefore means zipping them first and filtering the tuples, then unpacking again if you need the sequences back separately. That asymmetry between `map` and `filter` is itself a small interview probe: candidates who have only ever seen the one-iterable `map` usually assume both take `*iterables`. ### Summary One iterable per parameter, lockstep advance, stop at the shortest, no padding, no strict mode, and every error deferred to the first consumption. If length equality is part of your contract, assert it - `map` will not.