Mutable default arguments: the value lives in a field of the function, and every call shares it

Base: the function remembers what it has no business remembering

The place to start is the bug everyone recognises on sight. A function puts what it is given into a list and returns it:

def acc(item, into=[]):
    into.append(item)
    return into
 
print(acc(1))       # [1]
print(acc(2))       # [1, 2] — and [2] was expected

The second call returned a list of two items although it was given one. Hence the rule everybody memorises: never write a list as a default argument.

But in that form the rule cannot help: it reads like an arbitrary prohibition, which is exactly why it gets broken. The question this lesson answers is not "what is forbidden" but when the thing after the equals sign is evaluated. If it were evaluated on every call, the behaviour above would be inexplicable. If it is evaluated once, when the def runs, then everything is explicable — including the cases with no lists in them at all.

The second is what happens: the value is evaluated once, and the resulting object is handed to every call in which that argument is not passed. The list does not vanish between calls, because there is only one of it.

That is already enough to answer the basic interview question. Everything below is about where exactly that object lives and how to see it, what else breaks for the same reason, and what the correct version really costs.

Mechanism 1: where the default value lives

The reference describes the mechanism in two sentences — and that is enough to derive everything else.

That "pre-computed value" is not an abstraction — you can pick it up by hand:

def acc(item, into=[]):
    into.append(item)
    return into
 
print(acc.__defaults__)     # ([],)
acc(1)
acc(2)
print(acc.__defaults__)     # ([1, 2],)

The function's field grows along with the list. There is no special magic in the bug: the list was created once, put into the field, and handed out from there to every call in which that argument is not passed explicitly. A call like acc(3, []) takes no part in this picture at all — it works on its own list, and the field stays as it was.

Mechanism 2: the same mechanism, a second trap

Mutability is the half everyone remembers; the moment of evaluation is the half they forget. Both come out of the same moment.

TIMEOUT = 5
 
def fetch(url, timeout=TIMEOUT):
    ...
 
TIMEOUT = 30        # fetch will still take 5

And the most expensive manifestation:

import time
 
def log(message, at=time.time()):
    ...            # at is the module's import time, forever

Such a function never breaks and never raises anything. It simply writes the same timestamp into every record, and nobody notices until someone actually needs the logs.

Mechanism 3: the fix, and when None will not do

The reference offers the solution immediately:

def acc(item, into=None):
    if into is None:
        into = []
    into.append(item)
    return into

The function's field then stays (None,) forever — None is immutable, there is nothing in it to spoil.

But None does not always fit. If None is a legitimate argument value, the check cannot tell "not passed" from "passed None":

MISSING = object()
store = {"k": None}          # the dictionary being searched
 
def get(key, default=MISSING):
    value = store.get(key, MISSING)
    if value is MISSING:
        if default is MISSING:
            raise KeyError(key)
        return default
    return value

Here get("k", None) must return None while get("k") must raise KeyError, and only a sentinel of your own can tell them apart. The sentinel costs 8.07 ns more than None — not because of the comparison but because of the load: None compiles to a constant, while the sentinel lives among the module's globals. That is not, of course, why it gets chosen: it gets chosen because None is taken in such a function.

Mechanism 4: when it is done on purpose

The trick does have one use: a dictionary in a default argument is state that survives between calls.

def fib(n, _cache={0: 0, 1: 1}):
    if n not in _cache:
        _cache[n] = fib(n - 1) + fib(n - 2)
    return _cache[n]

It works. But it has three problems, and the third came as a surprise.

The first two are obvious: the cache can only be cleared from outside through fib.__defaults__, and anyone who calls fib can substitute the cache with a second argument — by accident or on purpose.

The third is speed, and the expectation here was the opposite. The hand-rolled cache seemed bound to beat functools.lru_cache: that one has a wrapper and this one does not. On a warmed-up cache it came out the other way round:

lru_cache is 1.43 times faster. The reason is that its wrapper is written in C and does one dictionary lookup, while the Python body does two — the not in check and the read — plus the function call itself. The C wrapper turned out cheaper than an extra lookup plus a Python-level call.

Mechanism 5: the same thing in classes

The mechanism is the same, and the dataclasses documentation opens its explanation with exactly that: "Python stores default member variable values in class attributes."

class C:
    items = []          # one list for all instances
 
o1, o2 = C(), C()
o1.items.append(1)
print(o2.items)         # [1]

Dataclasses are the one automatic check for this mistake I know of in the standard library. Its boundary is narrower than it looks:

@dataclass
class Bad:
    items: list = []
# ValueError: mutable default <class 'list'> for field items
#             is not allowed: use default_factory

The check sits in the decorator itself and fires when the class is defined. But it has a boundary of its own: it goes by hashability, not by mutability. list, dict and set are forbidden, while a class of your own with mutable state passes silently — and the instances will share one object. In an ordinary function there is no such check at all: only linters do it.

Deeper: what it costs

One argument in defence of a mutable default is still standing: "at least it is faster without the check". The argument is true: 32.67 ns against 48.78, that is, 49% more. The breakdown shows what exactly is being paid for:

• 11.37 ns — creating the new list. This is not overhead but the work the correct version exists to do: the broken one is cheaper precisely because it creates no list.
• 4.74 ns — the is None check itself.

So the real price of the check itself is five nanoseconds per call. The other eleven are the new list the broken version simply does not create.

And these numbers have the boundary any measurement has: one machine, one version. What carries over is not "49%" but the breakdown — what that difference is made of, and why comparing the two versions on speed is not a fair comparison at all: they return different things.

How to answer in an interview

The short answer: the expression after = is evaluated once, when the def executes, and the resulting object is handed to every call in which that argument is not passed. That is why a mutable default accumulates changes between calls. The fix is a None check; a sentinel of your own is needed only where None is a legitimate argument value.

That is enough for a correct answer. What follows is what you add when the interviewer digs.

If the interviewer digs deeper

What makes an answer good: showing f.__defaults__ — that turns the rule into a consequence. The value lives in a field of the function, the field is visible from outside, and the list in it grows from call to call; after that the rule does not have to be remembered, it can be derived.

And naming the other half of the mechanism: the value is evaluated at def time, which is why def log(at=time.time()) breaks for the same reason with no mutable object involved at all.

The phrasing itself is worth keeping precise. Not "one value for all calls" but the same object handed to every call in which that argument is not passed explicitly: pass your own value and the function's field plays no part at all. The bug lives neither in the list nor in the call but at their intersection.

Next they ask

Common misconceptions

Version history

Practice

Two exercises. Answer first, then check against the real output: in both, the right answer comes from a recorded run rather than from an editor.

def add(item, bucket=[]):
  bucket.append(item)
  return bucket


print(add(1))
print(add(2))
print(add.__defaults__)

[1]
[1, 2]
([1, 2],)

[1]
[2]
([],)

[1]
[1, 2]
([],)

[1]
[2]
([1, 2],)

Check yourself

What measured this

The numbers in this article come from these scripts. Each one opens from here, together with the record of the run: what it was measured on, what came out, and with what spread.

• bench/defaults/cost.py
• bench/defaults/where.py