Why does a mutable list defined in a Python class body end up shared by every instance?

### What actually happens A class body is ordinary code that runs exactly once, when the `class` statement is executed at import time. The names it binds become the class's namespace. So writing ```python class Reconciler: unmatched = [] ``` evaluates the display `[]` **once**, producing a single list object, and binds it in `vars(Reconciler)`. It is not a template, not a declaration and not a per-instance initialiser - Python has no concept of "this expression is re-evaluated for each object". Now consider an instance calling `self.unmatched.append(row)`. That line does three things in order: look up `self.unmatched`, get the `append` method of whatever came back, call it. The lookup finds nothing in the instance's own `__dict__`, falls back to the classes in `type(self).__mro__`, and returns the one list on the class. `append` then mutates that object in place. **No assignment happened**, so no instance attribute was ever created - `vars(instance)` stays empty, and every other instance, present and future, sees the appended row. ### Why this survives review The bug is invisible in the mutating method, because `self.unmatched.append(...)` reads exactly like per-object state. It is also invisible in a unit test that constructs one object, exercises it, and asserts on it - the shared list happens to be empty at the start of the first test and the assertions pass. It shows up as cross-contamination the moment two objects live at once, and as unbounded growth the moment the process is long-lived. A concrete shape: a payment reconciliation job creates one `Reconciler` per batch and appends every unmatched transaction to `self.unmatched` for the report. Each batch's report is correct only for the first batch; from then on each report also contains every earlier batch's rows. Worse, nothing ever drops those rows - the class object lives as long as the module, so the list is reachable forever and the process's working set grows monotonically, past 2.4 GB in a job that runs all night. Restarting the process "fixes" it, which is exactly the signature that sends people hunting for a leak in the wrong place. ### Mutation versus rebinding The distinction that explains the whole thing is mutation versus rebinding. * `self.unmatched.append(row)` - mutates the shared object. Nothing is written to the instance. * `self.unmatched = []` - rebinds. It stores a new list in the instance's `__dict__`, which from then on shadows the class attribute for that one object. * `self.unmatched += [row]` - the confusing middle case. The augmented assignment mutates the shared list in place *and then* stores that same object in the instance `__dict__`, so you get both effects at once: the shared list still grew, and the instance now holds a reference to it. This is why an immutable class attribute is safe. `retries = 3` cannot be mutated; any attempt to "change" it through an instance is necessarily an assignment, which shadows cleanly and leaves other instances alone. The danger is confined to mutable containers and mutable objects - lists, dicts, sets, and any custom object with mutating methods. ### The fix, and the alternatives The fix is to create the object per instance: ```python class Reconciler: def __init__(self): self.unmatched = [] ``` If you want a declarative class-body default, use an immutable one and copy it, or use a dataclass field factory - the underlying rule is the same: whatever creates the object must run per instance, not once per class. Deliberately shared mutable class state is occasionally what you want - a registry of subclasses, a process-wide cache - but then it should be named and documented as class state and touched through the class (`Reconciler.registry`), never through `self`, so no reader mistakes it for per-object data. Add thread-safety to that decision too: a shared class-level container is shared across every thread in the process. ### Spotting it Three quick checks: `vars(instance)` is empty where you expected state; `a.unmatched is b.unmatched` is `True` for two independent objects; and `"unmatched" in vars(type(a))` is `True`. Static analysers and third-party linters flag mutable class-body defaults, and a review habit of asking "does this class body build a container?" catches it before it ships.