skip to content

What does the initializer argument to functools.reduce() change about the result?

level: middleimportance: should knowfreq 45%

answer

  1. A left fold with one accumulator
  2. The starting value for the accumulator
  3. Identity element: 0, 1, empty dict
  4. Empty input without it raises
  5. Demoted out of the builtins in 3.0

basics

~20 s

It is the starting accumulator, combined before the first item. It seeds the result type, makes an empty iterable return it rather than raise TypeError, and forces the function to run even for a one-element input.

solid answer

~50 s

`functools.reduce(function, iterable, initializer)` is a left fold: it calls `function(accumulator, next_item)` repeatedly, threading the result forward. Supplying the initializer changes three things - it seeds the accumulator's **type** (start from `{}` or `0` rather than whatever the first element happens to be), it makes a one-element iterable still invoke the function once, and it makes an empty iterable return the initializer instead of raising `TypeError`. Without it, a single-element input is returned as-is without calling the function at all, which hides type bugs. `reduce` was a builtin in Python 2 and moved into `functools` in Python 3.0 - it was already available as `functools.reduce` from 2.6 - because Guido considered most folds unreadable compared with `sum()`, `any()`, `all()`, `min()`, `max()` or `str.join()`. Reach for it only when you need an associative combine that no built-in aggregate covers.

code

python · 9 lines
python
from functools import reduce
from math import prod

def merge(acc, chunk):
    return acc | chunk

print(reduce(merge, [{"a": 1}, {"b": 2}], {}))  # {'a': 1, 'b': 2}
print(reduce(merge, [], {}))                     # {} - no exception
print(prod([1, 2, 3, 4]))                        # 24, no fold needed

go deeper

for a junior

Recall that reduce lives in functools, not the builtins, and that it collapses a sequence to one value by combining two at a time from the left.

for a middle

Explain the initializer precisely: it seeds the accumulator type, makes an empty input return it instead of raising TypeError, and forces the function to run even for a single-element input.

for a senior

Demonstrate the judgment to prefer sum, any, all, min, max, join or math.prod, to spot the quadratic fold over strings or lists, and to choose a plain loop when the accumulator carries real state.

for a principal

Own the readability standard: decide when a functional fold is acceptable in a shared codebase versus an explicit loop, and make the empty-input contract - identity value or error - an explicit design decision rather than an accident.

### What reduce actually does `functools.reduce(function, iterable[, initializer])` performs a **left fold**. It keeps a single accumulator and walks the input, replacing the accumulator with `function(accumulator, item)` at each step, then returns the final accumulator. Folding `[a, b, c, d]` with `f` computes `f(f(f(a, b), c), d)`. The function always takes exactly two arguments: the running result and the next element. Unlike `map` and `filter`, `reduce` is **eager** - it consumes the whole input and returns a single value, not an iterator. ### The three things the initializer changes **1. It seeds the type.** Without an initializer, the accumulator starts as the *first element*, so the result's type is dictated by the data. Folding a list of dicts starts from someone else's dict - and if the fold mutates the accumulator in place, you have just corrupted the caller's first element. With `{}` as the initializer, you start from a fresh object you own. **2. It fixes the empty case.** `reduce(f, [])` with no initializer raises `TypeError`, because there is nothing to return. `reduce(f, [], 0)` returns `0`. Real inputs are empty far more often than people plan for - a filtered list, a query with no rows, a batch that got fully deduplicated - so the initializer is usually the difference between a sane identity value and a crash on a Tuesday. **3. It normalises the one-element case.** `reduce(f, [x])` with no initializer returns `x` **without ever calling `f`**. That sounds harmless until `f` is doing the type conversion or validation you assumed always ran; with a single-item input, it silently does not. `reduce(f, [x], init)` calls `f(init, x)` and behaves like every other input size. Put plainly: the initializer supplies the *identity element* of the operation - `0` for addition, `1` for multiplication, `{}` or `set()` for merging, `""` for concatenation - and it is what makes the fold total instead of partial. ### Why reduce is not a builtin any more In Python 2 `reduce` was a builtin. Python 2.6 also exposed it as `functools.reduce`, and **Python 3.0 removed the builtin**, leaving only the `functools` spelling. The stated reasoning was readability: Guido van Rossum's view was that outside of the handful of trivial cases, reading a `reduce` call means mentally simulating the loop to work out what the accumulator holds, whereas the equivalent `for` loop or a purpose-built aggregate says it directly. Python's answer to "fold this sequence" is a set of specialised builtins rather than a general fold: * summing numbers - `sum(items)` * logical folds - `any(items)`, `all(items)` * extremes - `min(items)`, `max(items)`, with `key=` for anything non-trivial * joining strings - `"".join(parts)`, never a fold with `+`, which is quadratic * products - `math.prod(items)` since Python 3.8 Each of those is a fold in disguise, each is faster than the Python-level equivalent, and each names its intent in the call. The extra import of `functools` is a small, deliberate speed bump reminding you to check whether one of them fits. ### When reduce is still the right tool It earns its place when the combine is genuinely associative, has no dedicated builtin, and the alternative loop would be pure boilerplate: merging a sequence of dictionaries or sets, OR-ing together a list of bit flags, composing a list of transformation functions into one, or intersecting a series of collections. In those cases the fold is one short line, the accumulator's meaning is obvious, and there is nothing clearer to reach for. It is the wrong tool when the function has side effects, when the accumulator carries several pieces of state that would need packing into a tuple, when the combine is not associative and reading order matters to a maintainer, or when an explicit loop would let you name intermediate values. **A three-line `for` loop that a stranger reads once beats a one-line fold they read three times.** ### Cost traps Folding with `+` over strings or lists is the classic performance trap: each step allocates a new object and copies everything so far, giving quadratic behaviour. `str.join` and a single `list.extend` loop are linear. Similarly, folding with `|` over dicts allocates a new dict per step; for large inputs an explicit loop with `update` on one accumulator is linear rather than quadratic. ### Interview framing When asked about `reduce`, the expected shape of a good answer is: define the left fold, explain the initializer as the identity element that makes empty and single-element inputs behave, name Python 3.0 as the release that demoted it, and finish with the judgment - most folds should be a builtin aggregate or a plain loop, and `reduce` is for the associative combine that has neither.

  • Which built-in aggregates would you reach for before functools.reduce?
    `sum()` for numbers, `any()` and `all()` for boolean folds, `min()` and `max()` with a `key=` for extremes, `str.join()` for concatenating strings, and `math.prod()` (Python 3.8+) for products. Each is a specialised fold implemented in C, so it is both faster and self-describing. `reduce` is the fallback for an associative combine none of them cover, such as merging dicts or OR-ing bit flags.
  • What is wrong with reduce(lambda a, b: a + b, list_of_strings)?
    It is quadratic. Every step allocates a new string and copies everything accumulated so far, so total work grows with the square of the input size. `"".join(list_of_strings)` measures the total length once, allocates once and copies each piece once, which is linear. The same trap applies to folding lists with `+` instead of building one list and extending it.
  • Why does reduce live in functools in Python 3 rather than in the builtins?
    Python 3.0 removed the builtin, leaving the `functools.reduce` spelling that had existed since 2.6. The reasoning was readability: reading a fold means simulating the accumulator in your head, while `sum()`, `any()`, `all()`, `min()`, `max()`, `str.join()` and `math.prod()` name the intent and run in C. The extra import is a deliberate nudge to check whether one of those fits first.
  • Is functools.reduce a left fold or a right fold, and does that matter?
    A left fold: it starts at the beginning and threads the accumulator forward, computing `f(f(f(a, b), c), d)`. Python ships no right fold. It matters whenever the combine is not associative - subtraction, division or function composition give different answers in the other direction - so for non-associative operations you must either reverse the input deliberately or write the loop explicitly.

The initializer is the empty shopping basket you carry into the shop. Without it you grab the first item off the shelf and use it as the basket - which works until the shop is empty, or until you tip everything into somebody else's bag.

saying these in an interview costs you the question

  • Calling reduce a builtin in Python 3
  • Thinking the initializer is just a default result
  • Assuming empty input returns None without an initializer
  • Not knowing one item skips the function entirely
  • Folding strings with + instead of str.join
  • Reaching for reduce where sum or any is clearer

context

resolving links…