What does @dataclass(frozen=True) actually prevent, and what does it not?

## What the decorator actually generates `@dataclass(frozen=True)` does not produce a special immutable object. It decorates an ordinary class and adds two ordinary methods: a `__setattr__` and a `__delattr__` that raise `dataclasses.FrozenInstanceError`. Everything else — the generated `__init__`, `__repr__`, `__eq__` — is exactly what a non-frozen dataclass gets. The generated `__init__` has to bypass its own block internally in order to populate the fields once; after that call returns, every assignment through the instance is refused. The error type matters. `dataclasses.FrozenInstanceError` inherits from `AttributeError`, so a broad `except AttributeError` swallows it, and duck-typing code that probes with `setattr()` inside a `try` will silently treat a frozen instance as "attribute not supported" rather than "deliberately immutable". The message reads `cannot assign to field 'name'`. One detail that surprises people: on an instance of exactly the frozen class, *any* assignment is refused, not just assignment to a declared field. `obj.typo = 1` raises the same `FrozenInstanceError` — the generated `__setattr__` refuses everything when `type(self)` is the frozen class itself, and consults the field names only for subclass instances. ## The immutability is shallow This is the point interviewers are really testing. `frozen=True` freezes the *binding between the attribute name and the object*, not the object on the other end of that binding: ```python from dataclasses import dataclass @dataclass(frozen=True) class Reading: name: str tags: list[str] r = Reading("cpu", ["host:a"]) r.name = "mem" # FrozenInstanceError r.tags.append("x") # works fine, the list is a normal list ``` So a frozen dataclass is only as immutable as its field *types*. If you want real value semantics, use immutable field types: `str`, `int`, `tuple`, `frozenset`, other frozen dataclasses. A `list` or `dict` field re-opens every door `frozen=True` was meant to close, including the safe-sharing and thread-safety arguments people use to justify it. ## Hashability comes with it With the default `eq=True`, adding `frozen=True` is also what makes the class hashable — the decorator generates a `__hash__` instead of setting it to `None`. That is why frozen dataclasses can be dictionary keys and set members while plain ones cannot. (The full rule set for `eq`, `frozen` and `unsafe_hash` is a topic in its own right.) ## Inheritance must agree Frozen-ness is not a per-class choice inside a hierarchy. Deriving a non-frozen dataclass from a frozen one raises `TypeError: cannot inherit non-frozen dataclass from a frozen one` at class-creation time, and the reverse combination fails too. A frozen base therefore commits the whole subtree. Teams discover this when they try to add a "just one mutable subclass" escape hatch. ## Changing a frozen value The idiomatic replacement for mutation is `dataclasses.replace(obj, field=value)`. It reads the current field values, overrides the ones you name, and calls the class's normal construction path, so validation and derived fields run exactly as they do for a fresh object. Fields excluded from `__init__` cannot be passed to it. From Python 3.13 there is also a generic `copy.replace(obj, field=value)` that works on frozen dataclass instances and on any other type supporting the same protocol. The read side has two companions worth knowing. `dataclasses.fields(obj)` returns a tuple of `Field` objects describing the declared fields — name, type, default, flags — which is how generic serializers walk a dataclass. `dataclasses.asdict(obj)` returns a dict, converting nested dataclasses recursively and deep-copying everything else, which means the list in the output is a *copy* rather than the instance's own list; `dataclasses.astuple(obj)` does the same into a tuple. ## When to reach for it Use `frozen=True` for values that travel: configuration records, coordinates, identifiers, message payloads, cache keys. You get equality and hashing that match the data, safe sharing between components, and no action-at-a-distance when an object is handed to code you do not control. The costs are real but small — every "edit" allocates a new instance, and the Python-level `__setattr__` makes construction measurably slower than a plain dataclass, which matters only in hot allocation loops. What you do **not** get: deep immutability, a security boundary (the block is a normal method, and a determined caller can go around it), thread safety when a field holds a mutable container, or any kind of interning — two equal frozen instances remain two distinct objects.