Why does a class's __dict__ come back as a mappingproxy rather than a dict?

## The observation ``` >>> class Sync: ... retries = 3 ... >>> type(Sync.__dict__) <class 'mappingproxy'> >>> Sync.__dict__["retries"] = 5 Traceback (most recent call last): ... TypeError: 'mappingproxy' object does not support item assignment >>> Sync().__dict__ {} >>> type(Sync().__dict__) <class 'dict'> ``` A class namespace is read-only through `__dict__`; an instance namespace is a plain, writable dict. `vars(Sync)` returns the same proxy — `vars` is just `__dict__` with a nicer spelling. ## Why classes are special Attribute lookup on a class is not a dict lookup. It walks the method resolution order, consults descriptors, and — crucially — CPython caches the result per type so that repeated lookups do not re-walk the MRO. That cache is only correct while the interpreter knows when a type changed. In addition, certain dunder entries are mirrored into internal fields on the type object when they are set: defining `__len__` or `__eq__` on a class does not merely put a function in a dict, it also updates the machinery that `len()` and `==` actually consult. All of that maintenance hangs off `type.__setattr__`. Set the attribute the normal way and the interpreter invalidates its caches and refreshes the mirrored entries. Poke a value directly into the namespace dict and none of it happens: the new attribute might not be visible to code that had already looked the name up, and a dunder assigned that way might never take effect at all. Rather than leave that trap open, CPython never hands the writable namespace out. The `mappingproxy` is the enforcement mechanism. ## The supported ways to change a class at runtime * `Sync.retries = 5` or `setattr(Sync, "retries", 5)` — both route through `type.__setattr__`, which performs the write and the invalidation. `delattr(Sync, "retries")` is the removal counterpart. * Reading is unrestricted: `Sync.__dict__["retries"]`, `"retries" in Sync.__dict__` and iteration all work, and reading the namespace directly is genuinely useful — it shows what *this* class defines without inherited names, which plain attribute access cannot distinguish. * During the class body's execution the namespace is a real, writable mapping; only the finished type wraps it. That is why a metaclass can prepare and populate a namespace, and why decorators are given the class object afterwards and use `setattr`. One related limit: built-in and extension types refuse attribute assignment entirely. `str.foo = 1` raises `TypeError` saying the type is immutable, which is a separate rule from the proxy — the proxy blocks the back door, `type.__setattr__` blocks the front door for those types. ## Reading a class namespace well Because the proxy is a live view, `Sync.__dict__` reflects later `setattr` calls without being refetched. It is the right tool when you must distinguish own attributes from inherited ones — a registry that collects only the methods a subclass actually defines, for instance, or introspection that reports which of a base class's hooks were overridden. `dir()` and `getattr` flatten the MRO; `__dict__` does not. When you want a mutable working copy of the namespace, `dict(Sync.__dict__)` gives you one, which you can then compare or diff without touching the class. ## Why it is a good interview question It is not high-frequency and nobody is rejected for missing it, but it connects three things a strong candidate should already hold separately: what a `mappingproxy` is, that classes keep their attributes in a namespace mapping, and that the interpreter maintains caches whose correctness depends on going through the official mutation path. Candidates who have hit it usually hit it while writing a decorator or a plugin registry, tried the direct dict write because it read more explicitly, and learned from the `TypeError` that `setattr` is the API.