How does a class declaring `__slots__` store attribute values with no instance `__dict__`?

## Attribute lookup, and where slots sit in it For a normal instance, `obj.x` runs `object.__getattribute__`, which searches the type and its MRO first, then falls back to the instance's `__dict__`. The type search matters because of *descriptor* precedence: an object found on the class that defines `__set__` or `__delete__` is a **data descriptor**, and it wins over anything in the instance dictionary. `property` is the familiar example. `__slots__` reuses exactly that machinery. It adds no new lookup rule — it just installs one data descriptor per declared name: ```python class Row: __slots__ = ("amount",) print(type(Row.amount).__name__) # member_descriptor ``` `Row.amount` is a real object living on the class. Its type is called `member_descriptor`, and it carries the offset of one fixed cell inside every `Row` instance. That cell holds a reference to the stored value, exactly as a dictionary slot would, but its position is decided once, at class creation, instead of being looked up by hashing a string on every access. ## What each operation does * `r.amount = 42` → `object.__setattr__` finds the data descriptor on the type and calls its set hook, which stores the reference in the cell. * `r.amount` → the get hook reads the cell. If the cell is empty, it raises `AttributeError` naming the attribute — indistinguishable, from the caller's side, from an attribute that was never declared. * `del r.amount` → the delete hook empties the cell and drops the reference. A subsequent read raises again. Because the descriptor is on the class, you can drive it explicitly: `Row.amount.__get__(r, Row)` and `Row.amount.__set__(r, 42)` do exactly what the attribute syntax does. That is only a debugging party trick, but it is the clearest demonstration that nothing magical is happening — slots are ordinary descriptor protocol over fixed storage. ## The rules this explains **A same-named class variable is a ValueError.** The descriptor must be stored in the class namespace under the declared name. A class body that also assigns that name would overwrite it, so class creation refuses the collision outright rather than silently dropping one of them. **Re-declaring an inherited slot creates a second one.** If a base declares `("x",)` and a subclass declares `("x",)` again, the subclass gets its own descriptor over its own cell, and it shadows the parent's on lookup. The parent's cell still exists and is now unreachable through normal attribute access — it is wasted storage plus a real correctness trap, because a base-class method written against the parent descriptor and a subclass method written against the child descriptor read two different cells. The rule is simple: never repeat a name your base already declared. **Data-descriptor precedence still applies when a `__dict__` exists.** If a slot-less base in the MRO reintroduces an instance dictionary, the slot descriptors do not stop working, and they do not lose. Assignment still goes into the slot cell, because a data descriptor found on the type outranks the instance dictionary. Only names *not* covered by a descriptor land in the dictionary. **Properties and slots coexist, but not under the same name.** Both are data descriptors on the class, so `property` behaves normally on a slotted class — a common pattern is a private slot `("_amount",)` plus a public `property` named `amount` that validates on the way in. ## What it does not give you The descriptor stores a plain object reference. It performs no type check, no coercion and no validation; declaring a slot constrains the *set of names*, never the values. If you want checked values you write a property or your own descriptor class on top. It also does not make attribute access thread-safe or atomic beyond what a normal attribute assignment already is, and it does not change how `getattr`, `setattr` and `hasattr` behave — those route through the same `__getattribute__` path and therefore through the same descriptors. ## Version note This mechanism has been stable for the whole Python 3 line and is unchanged in 3.14; the descriptor type name and the offset-based storage are CPython implementation details that other implementations may realise differently while keeping the same observable semantics.