Why do dict.get() and the in operator bypass an overridden __getitem__ in a dict subclass?

Two very different operations both get called "a dict lookup", and only one of them goes through your class. **Syntax goes through the type; C methods do not.** When you write `d[key]`, the interpreter resolves the subscript slot on `type(d)` and calls it. If your subclass defines `__getitem__`, that is the function that runs. When you write `d.get(key)`, `key in d`, `d.values()`, or hand `d` to a C consumer such as the JSON encoder, none of those consult `type(d).__getitem__`. They are separate C functions defined on `dict` that walk the hash table stored inside the object and hand back whatever is stored there. Overriding `__getitem__` overrides *one entry point* into that table; it does not replace the table or the other doors into it. **Why CPython works this way.** An instance of a `dict` subclass really is a `dict` at the C layer: same storage, same layout, and C code can check for it cheaply and then read it directly. `dict.get`, `dict.__contains__`, `dict.setdefault`, `dict.pop`, `dict.copy` and the view objects are all implemented over that structure. Making each of them re-enter the interpreter to look for a possibly-overridden `__getitem__` would put a full Python-level call on every read of every dict in the program, for the benefit of the rare subclass that overrides it. So they read the table. This is a CPython implementation trait rather than a language guarantee, but it has held for the entire 3.x line and is unchanged in 3.14. **Concretely, for a subclass whose `__getitem__` transforms values on read:** ```python import json class Vault(dict): def __getitem__(self, key): return super().__getitem__(key).upper() v = Vault(token="secret") v["token"] # 'SECRET' -> override ran v.get("token") # 'secret' -> bypassed "token" in v # True -> dict.__contains__, override irrelevant list(v.values()) # ['secret'] -> the view reads the table json.dumps(v) # '{"token": "secret"}' dict(v), {**v}, v.copy() # all raw, and copy() returns a plain dict repr(v) # raw as well ``` `json.dumps` is the one that bites in production. With default arguments it uses the C-accelerated encoder, and for anything that passes an `isinstance(o, dict)` check it iterates the underlying table directly — it never calls `.items()`, `.get()` or `__getitem__`. So the object you serialise into a log line or an HTTP body carries the raw stored values, while the hand-written code path you tested in the REPL with `v["token"]` looked perfect. **The diagnostic rule.** Subscript syntax (`d[key]`, `d[key] = x`, `del d[key]`) reaches `__getitem__` / `__setitem__` / `__delitem__`. Anything spelled as a method on the built-in type, and any consumer that treats the object as a concrete dict, does not. Note that `key in d` *looks* like syntax but resolves to `__contains__`, which `dict` already implements in C — so overriding `__getitem__` has no effect on it. If you want certainty for a given call, instrument the override with a counter or a print and exercise the real code path; guessing which stdlib function takes the fast path is how this bug ships. **The two honest fixes.** 1. **`collections.UserDict`.** It is not a `dict` at the C layer — it is a Python `MutableMapping` that keeps the real mapping in a plain attribute and implements the mapping interface in Python. The mixin methods it inherits from `collections.abc.Mapping` and `collections.abc.MutableMapping` are written in terms of `self[key]`, so `get()`, `pop()`, `setdefault()`, `values()` and `items()` all route through your override. The costs are real: every operation is a Python-level call, and because the object is not a `dict`, C consumers that demand a concrete dict reject it — `json.dumps` raises `TypeError` unless you serialise the inner mapping or pass a `default` hook. One wrinkle even here: `UserDict` defines `__contains__` as a direct check against its inner mapping, so membership still skips your override. 2. **Composition with an explicit API.** Stop advertising a mapping. Hold the storage privately and expose a named method — a `read(key)` that decrypts, a `fetch(key)` that lazily loads. Nothing in the runtime has a fast path for a method you invented, so nothing can bypass it, and callers can no longer accidentally reach the raw values by writing `.get()`. **The point an interviewer is testing.** Subclassing a built-in container inherits the C type's speed and its shortcuts together. You get to intercept only the operations routed through type slots, which is a small and non-obvious subset. When the override carries semantics — decryption, lazy loading, auditing, redaction — partial interception is more dangerous than none, because the class behaves correctly in the paths you exercised by hand and silently leaks the raw values everywhere else.