A row class declares `__slots__`, yet its instances still accept a misspelled attribute. Why?

## The rule, stated precisely An instance has a `__dict__` if **any** class in its MRO gives it one. `__slots__` is the opt-out, and it opts out only for the class that writes it. Miss one class anywhere in the chain and every instance below it is dictionary-backed again. That single rule generates every symptom people report. **A slot-less base.** This is the common one, because the base often predates the decision: ```python class Base: # no declaration pass class Row(Base): __slots__ = ("amount",) r = Row() r.amoount = 1 # accepted; lands in the inherited __dict__ ``` `Row` genuinely has its `amount` slot and its descriptor, and the slot is still where `amount` is stored — data-descriptor precedence sees to that. But the object also carries `Base`'s dictionary, so every *other* name is accepted, and the typo-catching that motivated the declaration is gone. **A subclass that omits it.** The same failure, one generation later. `class Detailed(Row): pass` has no declaration of its own, so its instances get a dictionary even though `Row` was careful. **A mixin.** Mixins are the sneakiest case: a small `class LoggableMixin:` with two methods and no `__slots__` is enough to reopen every class that mixes it in. **`object` itself is fine.** Inheriting directly from `object` costs nothing — `object` gives its instances no dictionary. Only intermediate Python classes do. ## What a diagnosis looks like Take a nightly payment reconciliation job that loads a 6,800-row batch into a slotted row class. Rows normalise fine most nights, but the run that hits an encoding mismatch takes a retry path that sets `row.raw_payload` on the way through — a field nobody declared. Nothing raises. The retry records stash a second copy of every failed row's bytes, the batch's footprint climbs, and the "slots keep this bounded" assumption in the design doc turns out never to have held. The check is direct: build one instance and ask for its `__dict__`. If it answers instead of raising, something in the MRO is slot-less, and you find it by walking `type(obj).__mro__` and looking for a class whose own namespace has no `__slots__` entry — remembering that `__slots__` is not inherited as a summary, so you must test each class's own attributes, not just read the leaf's tuple. ```python for cls in type(row).__mro__: if cls is not object and "__slots__" not in cls.__dict__: print("slot-less:", cls.__name__) ``` The remedy is mechanical: declare `__slots__ = ()` on every class in the chain that adds no fields of its own. The empty tuple is the whole point of the idiom — it declares "I add no storage" while still opting out of the dictionary. ## The multiple-inheritance limit Slots reserve fixed storage in the instance layout, and two independent layouts cannot be merged. Deriving from two bases that each declare a *non-empty* `__slots__` raises `TypeError: multiple bases have instance lay-out conflict` when the class is created. There is no workaround at the language level; you restructure — put the storage on one base and keep the other a behaviour-only mixin declaring `__slots__ = ()`, which combines freely because it adds no layout. This is a real constraint on how far a slotted hierarchy can grow, and it is the honest argument against pushing slots through a deep class tree with several storage-carrying mixins. ## The deliberate escape hatch Listing `"__dict__"` inside the tuple gives instances both the fixed slots and a dictionary. It is a legitimate move when a framework or a third-party mixin needs to stash attributes on your objects, but in review it deserves a question: it restores exactly the behaviour the declaration was there to prevent, and it is often a quick silencing of an AttributeError whose real cause was a caller setting an undeclared field. ## Version note These inheritance rules are unchanged through Python 3.14. The one modern convenience worth knowing is that the standard-library dataclass decorator takes a `slots=True` option, which builds the declaration for you from the field list — useful, but it does not change any of the rules above, and the ancestors still have to cooperate.