Why does a `tuple` subclass with a nonempty `__slots__` fail at class-creation time?

## What `__slots__` actually does By default every instance of a Python class carries a `__dict__` for its attributes. Declaring `__slots__ = ("x", "y")` replaces that dictionary with descriptors that read and write fixed offsets inside the instance itself. That is where the memory saving and the small speed win come from — and it is also the constraint: the offset must be known when the type is created, and it must be the same for every instance of the type. ## Why `tuple` cannot host one Most objects have a fixed instance size, recorded on the type. A handful of built-ins are *variable-length*: the payload is stored inline in the object, immediately after the header, and each instance's total size depends on how much payload it holds. At the C level these types declare a nonzero `tp_itemsize`. `tuple` is one — the item pointers are part of the object — and so are `int`, whose digits are stored inline, and `bytes`. For such a type there is no offset that is past the payload for every instance, because the payload length varies per instance. Rather than silently corrupt memory, CPython refuses: ```python class Point(tuple): __slots__ = ("x", "y") # TypeError: nonempty __slots__ not supported for subtype of 'tuple' ``` The error fires while the `class` body is being turned into a type, so it is a hard startup failure, not something that waits for the first instance. Note also what the reason is *not*: immutability. A tuple subclass instance normally has a perfectly ordinary `__dict__` and you can set attributes on it. The problem is layout, not mutability. ## `list` is not variable-length in this sense It is worth contrasting, because it is the fact that makes the rule click. A `list` object holds a pointer to a separately allocated array of items; the list object itself is a fixed-size header. So the following is legal, and the slot lives at a known offset: ```python class Tagged(list): __slots__ = ("tag",) ``` The same is true of most classes people write. The rejection is specific to subtyping a variable-length built-in. ## The empty tuple is not a no-op `__slots__ = ()` is accepted on a tuple subclass and does real work: it declares that the class adds no per-instance attributes, so instances are created without a `__dict__`. The effects are memory (no dictionary per value) and discipline (a typo in an attribute name raises `AttributeError` instead of silently creating a new attribute). That is why the standard library's tuple-based record types declare an empty `__slots__`, and why a `typing.NamedTuple` instance has no `__dict__`: ```python import typing class Point(typing.NamedTuple): x: int y: int hasattr(Point(1, 2), "__dict__") # False ``` If you hand-roll a tuple subclass and want the same property, write `__slots__ = ()` yourself; it is easy to forget, and forgetting it silently reintroduces a per-instance dictionary on a type whose whole point was to be small. ## Where the extra state goes instead When you genuinely need a value that behaves like a tuple *and* carries something the tuple does not, the options are ordinary design choices rather than tricks: - Make the extra data another field of the tuple, exposed through a property, so it participates in equality, hashing and unpacking like everything else. - Accept the per-instance `__dict__`: drop `__slots__`, set the attribute in `__init__`, and pay a dictionary per value. Remember that the attribute will not survive `copy.deepcopy` or pickling unless you arrange for it, since reconstruction goes through `__new__` and the tuple's items. - Stop subclassing `tuple`. A frozen `dataclasses.dataclass` accepts a nonempty `__slots__`, gives you named fields, and is the better home for a value type that is not really a sequence. ## Why an interviewer asks it This is a curiosity question, not a gate. It comes up when a candidate reaches for `__slots__` to shrink a hand-rolled tuple subclass and hits the error live. What it tests is whether you can reason about object layout from first principles — fixed offsets need fixed sizes — instead of memorising which built-ins are on a list. The strong answer explains the layout in one sentence, notes that the empty form is allowed and useful, and moves on.