Why does dict.update() skip an overridden __setitem__ in a dict subclass?

## The mechanism When you write `class Tracked(dict)`, you inherit a type whose methods are C functions in CPython. `dict.update()`, `dict.__init__()`, `dict.setdefault()` and `dict.__ior__()` (the `|=` operator) are written against the concrete hash-table struct. They call the internal insertion routine directly. They do **not** perform an abstract `PyObject_SetItem` call, which is what would look up `__setitem__` on the object's type and find your override. By contrast, the *syntax* `d[key] = value` compiles to a `STORE_SUBSCR` instruction, which does go through the type's `__setitem__` slot — and that slot is your Python function. That single asymmetry is the whole phenomenon: ```python class Tracked(dict): def __setitem__(self, key, value): print("tracked", key) super().__setitem__(key, value) d = Tracked() d["a"] = 1 # tracked a d.update({"b": 2}) # silent d |= {"c": 3} # silent d.setdefault("e", 4) # silent Tracked({"f": 5}) # silent - dict.__init__ inserts directly ``` The same holds on the read side. An overridden `__getitem__` is used by `d[key]`, but `dict.get()`, the `in` operator, `dict.pop()`, `dict.items()` and iteration all read the table directly and never call it. ## Why the language works this way Two reasons, and neither is an accident. The first is speed: dictionaries are the substrate of attribute lookup, globals and keyword arguments, so their built-in methods take the shortest possible path and cannot afford a dynamic attribute lookup per insert. The second is that this is simply the ordinary rule for built-in types written in C — CPython's C-level implementations of built-ins are not obliged to re-dispatch through the Python type. The `dict` docs say so plainly: a subclass that wants consistent behaviour must override every method it cares about, because the base implementations are not guaranteed to call each other. The rule is not even uniformly *one* way, which is why memorising a list beats reasoning from a principle. `dict.fromkeys()` on a subclass, for instance, does route inserts through `__setitem__`, because it builds the new object through the abstract item-setting protocol. Deriving the behaviour from intuition will mislead you; testing it, or reading the source, will not. ## What breaks in practice The failure mode is always *partial* correctness, which is the worst kind. A case-normalizing mapping normalizes keys assigned one at a time and stores the raw keys arriving through a bulk `update()`. A validating mapping validates interactive writes and lets a batch load in unvalidated data. An auditing mapping records some writes. Nothing raises; the container is simply inconsistent, and the inconsistency depends on which call site touched it. There are also secondary surprises. `dict.copy()` on a subclass returns a plain `dict`, not your class — so does a `{**d}` expansion — which means state you added on the subclass silently disappears at the first copy. ## The three ways out **Override everything.** Keep inheriting from `dict` — you keep the C-speed reads and the fact that every consumer expecting a real `dict` accepts your object — but explicitly redefine `update`, `__init__`, `setdefault`, `__ior__`, `pop`, `copy` and anything else you rely on, funnelling each through your own `__setitem__`. It works, it is easy to leave a hole in, and each new dict method in a future release is a new hole. **Wrap instead of inherit.** `collections.UserDict` holds a real dictionary in an attribute and implements every mapping operation in Python on top of `__getitem__`/`__setitem__`, so a single override covers the whole surface. You pay in speed and in the fact that the result is not an instance of `dict`. **Do not subclass a container at all.** Often the honest answer: expose a small class with the two or three domain operations you actually need — `record()`, `lookup()` — and keep a private dictionary inside it. You then owe callers no mapping semantics whatsoever, and no one can reach past your API with an inherited method. ## What to say in an interview State the mechanism (built-in C methods bypass the Python-level slot), name at least `update`, the constructor and `setdefault` as concrete bypassers, note that the read side has the same hole, and finish with the design point: inheriting from a built-in container advertises a full contract you are only partly implementing. That last sentence is what separates a candidate who has read about the trap from one who has been bitten by it.