Classes, dataclasses, and __slots__: generated boilerplate and the per-instance dict

By the end you will know which one line cuts that 8 GB pod to 3 GB — and which follow-up surprise two sprints later proves the tradeoff is real.

What a class statement actually does

class Candle: is runtime code, not a declaration: Python executes the body in a fresh namespace, then calls type(name, bases, namespace) to manufacture the class object. Methods are just functions that landed in that namespace; Candle.__dict__ is where lesson 2’s attribute lookup finds them. Two consequences matter daily. First, class-body assignments run once — a mutable class attribute (cache = {}) is shared by every instance, the classic shared-state bug. Second, since the class is built by calling type, anything can hook that call — decorators like @dataclass post-process the finished class, which is exactly how it adds methods without metaclass magic.

@dataclass mechanics: what is generated, and the eq/hash interplay

@dataclass reads the class annotations and synthesizes the boilerplate: __init__ (parameters in annotation order), __repr__, and __eq__ comparing the field tuple. The defaults you must actually know:

from dataclasses import dataclass, field

@dataclass
class Order:
    id: int
    tags: list[str] = field(default_factory=list)  # NOT tags: list = []
    note: str = ""        # plain defaults fine for immutables

@dataclass(frozen=True)   # __setattr__ raises; __hash__ generated
class Money:
    amount: int
    currency: str

• Mutable defaults: tags: list = [] raises ValueError at class-creation time — dataclasses force default_factory because a shared list default is the same once-executed-class-body bug as above. (Plain classes let you make this mistake silently; dataclasses turned it into an error.)
• eq/hash interplay — lesson 1’s contract, now in generator form: default eq=True gives you __eq__ and therefore __hash__ = None; instances are unhashable. frozen=True makes instances immutable (assignment raises FrozenInstanceError) and, with eq=True, generates a field-based __hash__ — frozen dataclasses are safe dict keys. The escape hatch eq=True, unsafe_hash=True hashes a mutable class and is named “unsafe” for the lesson-1 reason: mutate a hashed field and the object is lost in its bucket.
• order=True adds __lt__/__le__/… comparing field tuples — handy for sorted(), wrong if field order is not your semantic order.

slots: trading the dict for memory and speed

If you are loading millions of uniform objects and your process RSS is suspiciously higher than the raw payload math suggests, the first question to ask yourself is: does every instance carry a __dict__ it never needs?

Declaring __slots__ = ("ts", "o", "h", "l", "c") tells class creation: do not give instances a __dict__; instead allocate fixed offsets in the C struct and create one slot descriptor per name (a data descriptor — lesson 2’s machinery — that reads/writes the offset). The honest numbers: a plain empty object is ~56 bytes plus its __dict__ at ~64–100+ bytes once populated (Python ≥3.3 key-sharing dicts soften this for uniform classes, but the dict still dominates small objects); a slotted instance stores just the references — for the five-field Candle, roughly 104 bytes total versus ~250+ with a dict, which is how 8 GB became 3 GB in the Hook. Attribute access gets ~10–25% faster too: a fixed-offset read beats a dict probe.

The costs are structural, not cosmetic. No __dict__ means no dynamic attributes (candle.debug_flag = 1 raises AttributeError), no vars(obj), and some dict-dependent tooling (naive serializers, functools.cached_property, monkeypatching in tests) breaks. Inheritance is where slots quietly fail: a subclass without its own __slots__ reintroduces __dict__ and the savings evaporate; multiple inheritance from two classes that both define non-empty __slots__ raises TypeError: multiple bases have instance lay-out conflict. And slots are per-class: each subclass declares only its new fields. Dataclasses integrate directly since Python 3.10: @dataclass(slots=True) regenerates the class with __slots__ built from the fields — the ergonomic default for high-volume value objects.

When NamedTuple or attrs instead

typing.NamedTuple gives you an actual tuple: immutable, hashable, iterable, unpackable, ~equal memory to slots — right for small value records that flow through code expecting tuples, wrong when you need mutation or methods that evolve state (and its equality-with-plain-tuples can surprise: Point(1, 2) == (1, 2) is True). attrs predates dataclasses, and earns its dependency when you want validators/converters on fields without writing descriptors by hand. Rule of thumb: dataclass by default, slots=True at volume, frozen for dict keys, NamedTuple at API boundaries that speak tuples, attrs when field-level validation pulls its weight.