Why does `def record_bid(price, log=[])` keep values from earlier calls?

## What actually happens A `def` statement is executable code, not a declaration. When the interpreter reaches it — usually while importing the module, at process start — it evaluates the default expressions **once**, builds a function object, stores the results in it, and binds the name. From then on the defaults are fixed objects attached to the function: ```python def record_bid(price, log=[]): log.append(price) return log record_bid(120) # [120] record_bid(340) # [120, 340] <- same list record_bid.__defaults__ # ([120, 340],) ``` `__defaults__` is the whole story in one line: the tuple of default objects lives on the function, so the list has the lifetime of the function, not of a call. Every call that omits `log` gets that one list and appends to it. Nothing is being "remembered" by magic; the object was simply never re-created. With an immutable default the behaviour is identical but invisible. `def f(n=0)` also evaluates `0` exactly once and stores it, but no operation can change the integer `0`, so no state accumulates. That is why the trap only ever shows up with `list`, `dict`, `set`, a mutable instance of your own class, or an expression whose value should have been recomputed. ## The second, quieter failure The same rule bites when the default is a *computed* value rather than a container: ```python import datetime def stamp(event, at=datetime.datetime.now()): # frozen at import time return event, at ``` Every call reports the moment the module was imported, which on a long-running process is wrong by hours. This variant is worth naming in an interview because it shows you have understood the rule (defaults are evaluated once, at `def` time) rather than memorised the list case. ## The fix The conventional repair is the `None` sentinel: ```python def record_bid(price, log=None): if log is None: log = [] log.append(price) return log ``` Now a fresh list is created per call, and a caller who *wants* to accumulate into their own list can still pass one. Use `is None`, not a truthiness test: `if not log` would also replace an empty list the caller deliberately handed you. When `None` is itself a meaningful value for the parameter, use a private sentinel object instead: ```python _MISSING = object() def record_bid(price, log=_MISSING): if log is _MISSING: log = [] ... ``` An alternative that reads well for small containers is an immutable default plus a conversion: `def f(tags=()):` then `tags = list(tags)` in the body. It is safe because the default cannot be mutated, and it also relaxes the parameter to accept any iterable. ## Why Python does not simply re-evaluate Re-evaluating defaults per call would make every call pay for the expression and would make the semantics of a default depend on the caller's environment. Evaluating once also enables a well-known idiom: binding a value into a function at definition time, as in `lambda item, key=key: ...` inside a loop, where the default captures the current loop value rather than the variable. So the behaviour is deliberate, documented, and exploited on purpose — it only surprises you when the object it froze is mutable. ## Spotting and preventing it The pattern is mechanical, so it is worth catching mechanically. A mutable literal in a parameter list is a fixed shape that a linter flags, and it is one of the cheapest rules to switch on in a code-review checklist. In review, treat any `=[]`, `={}`, `=set()` or function call in a signature as a defect until proven otherwise. In debugging, the tell is state that survives across independent calls, and `f.__defaults__` confirms it in one line at the prompt. One clarification that often comes up: this has nothing to do with closures, globals or class attributes, and it is not affected by whether the parameter is keyword-only. It is purely about *when* the default expression runs and *what kind of object* it produced.