Why does @dataclass(slots=True) replace the class instead of modifying it?

## Why a decorator cannot bolt slots on When a `class` statement executes, Python builds the namespace, calls the metaclass, and the resulting type's instance layout is fixed at that moment. `__slots__` is one of the inputs to that construction: it tells the type machinery to allocate descriptor-backed storage per name and to omit the per-instance `__dict__`. Assigning `Cls.__slots__ = (...)` afterwards sets a class attribute that nothing reads — the layout has already been decided, and the instances still carry a dict. A decorator, by definition, runs after that. So `@dataclass(slots=True)` cannot mutate its way to slots. What it does instead is take the class's namespace, drop the field names' class-level defaults, add a `__slots__` tuple naming every field, and create a **new class** from that namespace with the same name, bases and metaclass. That new object is what the decorator returns and what the module-level name ends up bound to. The class the `class` statement produced is discarded. ## What that costs you **Identity.** Anything that captured the original class object still refers to it, and that object is not the class your instances belong to. The clearest case is decorator stacking, because decorators apply bottom-up: ```python registry = [] def register(cls): registry.append(cls) return cls @dataclass(slots=True) @register class Point: x: int registry[0] is Point # False isinstance(Point(1), registry[0]) # False ``` The `register` decorator ran first, on the original class; `@dataclass` then replaced it. Put the registering decorator **on top** and it captures the final class. The same hazard applies to a metaclass or `__init_subclass__` that stores subclasses during creation, to `super().__init_subclass__` bookkeeping, and to any module-level structure built from the class at definition time. **Class-level defaults are gone.** With slots, each field name on the class is now a slot descriptor, so a default that used to be readable as a class attribute is not: `Point.x` prints something like `<member 'x' of 'Point' objects>` rather than the default value. Code that introspects defaults must use `dataclasses.fields()` and read each `Field`'s default, which is the correct way regardless. **No ad-hoc attributes.** Instances have no `__dict__`, so `obj.temp = 1` raises `AttributeError`. That is often the point — it catches typos in attribute names — but it breaks patching-style code and some serialization helpers. **No weak references by default.** `weakref.ref(obj)` raises `TypeError: cannot create weak reference to 'Point' object`, because the weakref slot is part of the same layout decision. Pass `weakref_slot=True` (Python 3.11+) alongside `slots=True` when the objects need to live in a `WeakSet`, a weak-keyed cache, or an observer registry. **Conflicts are refused.** If the class body already defines `__slots__`, the decorator raises `TypeError: Point already specifies __slots__` rather than trying to merge. ## One thing that is *not* a problem on 3.14 Zero-argument `super()` relies on a hidden `__class__` closure cell that the compiler fills in with the class the method was compiled in — which, after the rebuild, is the discarded class. On Python 3.13 calling `super().__repr__()` from a method of a `slots=True` dataclass raised `TypeError: super(type, obj): obj (instance of Point) is not an instance or subtype of type (Point)`, one of the most confusing error messages in the language. On Python 3.14 the decorator updates that cell to point at the new class, and zero-argument `super()` works normally. If you are supporting older interpreters, the workaround is the explicit two-argument form, or leaving `slots=True` off that class. ## When to use it The reasons to pass `slots=True` — smaller instances and faster attribute access — are properties of the slot layout itself and apply to any class. What is specific to the dataclass flag is convenience: you get the slot names generated from the annotations, kept in sync automatically, and combinable with `frozen=True`. The judgement call is whether the class is a leaf value type (good candidate: many instances, fixed shape, no dynamic attributes, no mixin gymnastics) or a framework-facing class where something else may want to attach state, weak-reference it, or capture it at definition time. For a record type produced in bulk by a scraper or parser it is nearly free; for a base class in an extensible hierarchy it is a commitment worth stating explicitly.