Why does functools.cached_property raise TypeError on a class that defines __slots__?

## Two mechanisms with directly opposed goals `__slots__` exists to remove the per-instance dictionary. A normal instance carries a `__dict__` that can hold any attribute name; a slotted class instead declares its attribute names up front, and CPython lays them out as fixed offsets in the object, like struct fields. The payoff is smaller instances and slightly faster attribute access, which matters when a program holds a great many small objects — a chat-transcript archiver materialising a few million message records, say. `functools.cached_property` exists to write a computed value into that very dictionary. Its `__get__` does, in essence: ```python try: cache = instance.__dict__ except AttributeError: raise TypeError( f"No '__dict__' attribute on {type(instance).__name__!r} " f"instance to cache {self.attrname!r} property." ) from None ``` So the two features are not merely awkward together; one deletes the thing the other requires. The error is deliberate and specific — it names the class and the attribute rather than letting a raw `AttributeError` escape from inside the descriptor, because a bare `AttributeError` raised during attribute access is easily mistaken for "the attribute does not exist". ## The failure is lazy, which is the real trap Nothing is checked when the class is created. `__set_name__` runs, records the attribute name and is happy; the class imports, instances construct, and every other attribute works. The `TypeError` arrives the first time some code path actually reads the cached attribute. In practice that means a slotted class with a rarely-exercised cached attribute can pass a 340-case regression pack and still fail in production on the one branch nobody covered — and the failure surfaces mid-operation, so if that read sits inside a partial-failure rollback path, the rollback itself is what explodes. Treat "slots plus cached_property" as a static-analysis concern, not something tests will reliably catch for you. ## The fixes, and what each costs **Add `"__dict__"` to `__slots__`.** This is legal and restores a per-instance dictionary while keeping the declared slots as real slots: ```python class Row: __slots__ = ("payload", "__dict__") ``` It is one line and it works, but understand what you bought: the instance now carries a dictionary again, so most of the memory saving that motivated `__slots__` is gone. You keep the typo protection for the declared names only partially — arbitrary attributes can be set again, because the dict is back. If slots were added for discipline rather than memory, this is a reasonable trade; if they were added because you have millions of instances, it defeats the point. **Compute eagerly into a real slot.** If the value is always needed and not ruinously expensive, do it in `__init__` and store it in a declared slot. You lose laziness, you gain predictable cost and no descriptor at all. This is usually the right answer for slotted classes, because a class with slots is normally a class you are creating in bulk, and bulk creation with a lazily-cached expensive field is an unusual shape. **Hand-roll the lazy slot.** Declare a slot for the cache and a sentinel: ```python _MISSING = object() class Row: __slots__ = ("payload", "_size") def __init__(self, payload): self.payload = payload self._size = _MISSING @property def size(self): if self._size is _MISSING: self._size = len(self.payload) return self._size ``` This preserves both laziness and the memory win, at the cost of a `property` that runs its getter on every read — a data descriptor call rather than a dict hit. That is a small, constant, well-understood cost, and it is the standard pattern when both properties matter. ## Two adjacent facts worth knowing **Inheritance can rescue you accidentally.** A subclass that does not declare `__slots__` gets a `__dict__` automatically, so a slotted base with a `cached_property` may work fine through one subclass and fail through a sibling that declares its own slots. If you are debugging a `TypeError` that appears for some instances of an apparent hierarchy and not others, check which classes in the MRO declare slots. **A read-only mapping fails too, differently.** If `instance.__dict__` exists but does not support item assignment, the descriptor raises a second, distinct `TypeError` saying the dictionary does not support item assignment for caching that property. That is what you see if you try to hang a `cached_property` off something whose namespace is a read-only mapping proxy — a class object being the common case, since a class's `__dict__` is a mapping proxy rather than a plain dict. The one-sentence answer an interviewer wants: **`cached_property` needs a writable instance dictionary, `__slots__` removes it, and the mismatch is reported as a `TypeError` on first read rather than at class definition.**