When would you choose typing.NamedTuple over a dataclass for a record?

### What the class form gives you `typing.NamedTuple` is not a different data structure from `collections.namedtuple` — it is a nicer way to declare the same thing: ```python from typing import NamedTuple class Slot(NamedTuple): """One ad slot's bid state.""" campaign: str cpm_cents: int = 0 floor_cents: int = 0 def outbids(self, other: "Slot") -> bool: return self.cpm_cents > other.cpm_cents ``` You get annotations a type checker can use, defaults written where they read naturally, methods and a docstring in the class body — and an object that is still a tuple: `len(slot)` is 3, `list(slot)` gives the values, `a, b, c = slot` unpacks, `hash(slot)` works, and `Slot._field_defaults` reports `{'cpm_cents': 0, 'floor_cents': 0}`. The functional factory can do defaults too, via `namedtuple("D", ["a", "b", "c"], defaults=(1, 2))`, which fills the **rightmost** fields — but it cannot carry annotations or methods. ### The limits of the class form Defaults must be rightmost. `class Bad(NamedTuple): x: int = 1; y: int` raises `TypeError: Non-default namedtuple field y cannot follow default field x`, the same rule that governs function parameters. Inheritance is closed. A `NamedTuple` class cannot mix in another base: `class S(Base, NamedTuple)` raises `TypeError: can only inherit from a NamedTuple type and Generic`. If your record must participate in a class hierarchy, this is the fact that decides the question for you. All fields are public, there is no per-field metadata, and validation has no hook designed for it — you would have to override construction, which is awkward enough that it is a signal you wanted a different tool. ### What a dataclass gives instead A dataclass generates the same boilerplate — initialiser, `repr`, equality — onto an ordinary class. The differences that actually drive the decision: * **Mutability is the default.** Fields can be assigned. `frozen=True` makes them read-only and makes instances hashable, which is the configuration closest to a NamedTuple. * **No sequence behaviour.** An instance has no `len()`, does not unpack, does not index, and is never mistaken for a tuple by generic code. That is a loss of convenience and a gain in safety. * **Class-scoped equality.** The generated comparison requires the same class, so two record types with identical values compare unequal — the inverse of tuple behaviour, and the reason a dataclass is safer where several record types share a shape. * **Mutable defaults done properly.** A field can take a factory that runs per instance, so a list-valued default is not shared. A NamedTuple default is a single object evaluated once at class creation, with the same sharing hazard as a mutable function default. * **Room to grow.** Inheritance, a post-initialisation hook for validation and derived fields, per-field options for excluding a field from comparison or `repr`, and a `slots=True` option that recovers most of the memory advantage. ### Choosing Pick `typing.NamedTuple` when the record is a **value**: a coordinate, a price, a parsed row, a cache key. You want it immutable, hashable, cheap, and comfortable in sequence-shaped code — a return value of several related numbers is the classic case, since the caller can either unpack it or read fields by name. Pick a dataclass when the record is an **entity or a work item**: something that gets built up in stages, validated, subclassed, or that must not be interchangeable with another record of the same shape. Anything with more than a handful of fields also argues for a dataclass, because positional construction stops being readable and tuple ordering semantics stop being meaningful. A third option worth naming: a plain `dict` when the keys are genuinely dynamic. Both record types assume a fixed, known field set; if you find yourself checking whether a field exists, neither is the right shape. ### The memory question, honestly A NamedTuple instance stores only its values, so it is markedly smaller than a dict with the same keys — on CPython 3.14, `sys.getsizeof` reports 72 bytes against 184 for three fields. A dataclass with `slots=True` lands in the same neighbourhood as the NamedTuple, so memory alone rarely decides between the two; it decides between either of them and a dict, at scale. Choose on semantics — immutability, sequence-ness, equality scope — and treat the footprint as a tiebreaker.