The previous lesson ended with a confession: between __init__, __repr__ and __eq__, the Book class spends half of its lines reciting its own attributes — title, price, stock — over and over again. That repetitive code (called boilerplate) is so universal that Python automated it in the standard library: the @dataclass decorator generates those methods for you from a simple list of fields. In this lesson you'll rewrite Book in a third of the lines, meet field(), frozen=True and order=True, close the decision table that 04-06 left open (namedtuple, dict, class or dataclass?) and leave the Papyrus catalog in its definitive form: a dictionary of objects.

1. The boilerplate we all write the same way
2. @dataclass: three methods for free
3. Default values and field(default_factory=...)
4. __post_init__: validating at birth
5. frozen=True: immutable dataclasses
6. order=True: comparable and sortable
7. The definitive decision table: namedtuple vs dict vs class vs dataclass
8. Papyrus's final catalog: a dict of objects
9. Common mistakes and tips
10. Exercises with solutions

This is how Book ended up after 05-05 (just the repetitive part):

Fifteen lines in which each attribute appears five times. Adding an author field forces you to touch three methods, and forgetting one creates a silent bug (an __eq__ that ignores the new field). It's mechanical work — exactly what machines do best.

That's all. The @dataclass decorator (imported from dataclasses, standard library) reads the declared fields and automatically generates __init__, __repr__ and __eq__:

Two important clarifications:

• The annotations title: str or price: float are type hints, which we'll study in depth in module 8. For now, this is all you need: @dataclass requires them to detect the fields, and it does not validate types at runtime — Book(42, "hello") doesn't complain (yet; __post_init__ is coming right up).
• A dataclass is a perfectly ordinary class: it can have methods, properties (05-04), inherit and be inherited. It only saves you the boilerplate.

That's why we can add the usual behavior to it:

A subtle but crucial detail: BOOK_VAT = 0.04 without an annotation is an ordinary class attribute (05-01) and @dataclass ignores it as a field. With an annotation (BOOK_VAT: float = 0.04) it would become one more field of the __init__ — almost never what you want for a constant.

Default values work as they do in functions (stock: int = 0), and with the same trap from module 3: never a mutable object as a default value. @dataclass is even stricter than functions — it outright forbids it:

The solution is field(default_factory=...): instead of one shared value, you give it a function that manufactures a fresh value for each instance:

field() accepts more useful settings: field(compare=False) excludes a field from the generated __eq__/ordering, and field(repr=False) hides it from the __repr__ (handy for long histories).

Since __init__ is written by the decorator, where do we put the validations from 05-04? In __post_init__, a method the dataclass calls automatically right after the generated __init__:

Papyrus's business invariants — price ≥ 0, stock a non-negative integer — are protected at construction time. (Unlike the properties from 05-04, __post_init__ doesn't watch later assignments; if you need that, combine the dataclass with properties or use frozen=True, coming up next.)

@dataclass(frozen=True) produces immutable objects: any later assignment raises an error, as with the tuples and namedtuples of 04-02.

And here comes the prize 05-05 left pending: a frozen dataclass is hashable (it generates a __hash__ consistent with its __eq__), so its instances can go into sets and serve as dictionary keys (04-04):

Criterion: use frozen=True for value objects that represent identifying data (codes, coordinates, money); keep mutable the ones that model state that changes (a book's stock).

@dataclass(order=True) generates __lt__, __le__, __gt__ and __ge__ comparing the fields in their declaration order, like tuples:

The professional trick is in plain sight: declare the field you want to sort by first and exclude with field(compare=False) the ones that shouldn't influence the order. It's the generated alternative to writing __lt__ by hand (05-05); pick one route or the other, not both.

In 04-06 we closed the data structures with a decision table. OOP adds two columns and completes it:

Quick decision rule, from least to most structure: keys that change at runtime? → dict. Just an immutable record to read from? → namedtuple (or a frozen dataclass if you want validation). Named data, sensible equality, some behavior? → dataclass, the new default starting point. Does logic dominate over data (properties everywhere, an inheritance hierarchy with overrides, custom dunders)? → a full hand-written class. And the two mix freely: nothing prevents a dataclass with properties or a hierarchy whose base is a dataclass.

Let's close the circle opened in 04-03. The big refactor left the catalog as {title: {"price": ..., "stock": ...}}; module 5 takes it to its definitive form — a dictionary from normalized key to Book object — combining the best of both worlds: the dict's direct lookup by key and the object's intelligence.

Compare with the module's starting point: find_book() no longer walks the keys normalizing them one by one — the catalog was built normalized (dictionary comprehension, 04-03) and get() (04-03) resolves the lookup, missing-case included, returning None just like the original version. And what it returns is no anonymous sub-dictionary: it's an object that knows how to compute its price and report its stock.

• Forgetting the type annotation on a field: title = "x" without : str is not a field — it's a class attribute and disappears from the __init__. Every dataclass field carries an annotation; every class constant does not.
• A field without a default value after one that has one: stock: int = 0 followed by author: str gives TypeError (same rule as function parameters in 03-02). Order them: required fields first.
• A mutable default value: history: list = [] raises ValueError when the class is defined. Always field(default_factory=list) (or dict, set...).
• Expecting type validation from the annotations: Book(42, "hello") gets created without complaint. Annotations document (and module 8 tools will check them before running), but at runtime it's __post_init__ that validates.
• frozen=True with a __post_init__ that assigns: self.title = self.title.strip() fails with FrozenInstanceError even inside __post_init__. In frozen classes, validate without reassigning (or use object.__setattr__, an advanced trick you'll rarely need).
• Mixing order=True with a manual __lt__: the decorator refuses to generate ordering if you already define __lt__ (ValueError). One source of truth for the order, not two.
• Tip: faced with a new class, start with @dataclass. If over time it needs properties, complex inheritance or custom dunders, "promote" it to a full class: client code won't even notice, because the interface (book.price, book.final_price()) doesn't change.

Rewrite the Magazine class from 05-02 as a dataclass with fields title, issue, price and stock = 0, a __post_init__ that validates that issue is a positive integer, and the final_price(member=False) method with the canonical formula. Verify that Magazine("Quimera", 482, 6.50, 10).final_price(True) returns 6.42 and that issue=0 raises ValueError.

Create the dataclass SaleLine with frozen=True and order=True, and fields date (a "2026-07-13" string), title and amount — in that order, so the lines sort chronologically. Create three lines with different dates out of order, sort them with sorted() and check that a set removes a duplicate line.

Using the final Book dataclass and the dict[str, Book] catalog, write sell_title(catalog, wanted, member=False) that: looks up the book with find_book(); returns None if it doesn't exist; if it exists but there's no stock, returns the string "OUT OF STOCK: <title>"; and if there is stock, deducts 1 unit and returns the final price. Test with "hamlet" (member), "FAUST" and "Hopscotch".

Solution 1:

Four fields, validation and behavior in a third of the space the hand-written 05-02 version took.

Solution 2:

yyyy-MM-dd dates sort correctly as text — and in module 6 these sale lines will be exactly what we write into a CSV.

Solution 3:

Watch the whole module collaborate in ten lines: normalized lookup (04-05/05-06), an object that reports its own stock (05-01), a price computed by the book itself (05-01/05-02) and the catalog as a dict of objects. The three different outcomes (None, string, number) are begging for something better than "guess the return type" — the exceptions of module 7 will provide the elegant answer.

Module 5 delivers what it promised when module 4 closed: data and behavior no longer live apart. In 05-01, class, __init__ and self united the catalog with its functions and every book learned to compute its own member price; inheritance raised the Product → Book/Magazine → EBook family with super() distributing what's common (05-02); polymorphism let Ana's terminal charge for any item — even pedigree-free ducks like the GiftVoucher — by sending the same message (05-03); encapsulation armor-plated the business invariants with _internals and properties that reject impossible prices and stocks (05-04); the magic methods taught your objects Python's native language — print, ==, sorted, len, in, + — and settled the ugly print (05-05); and dataclasses eliminated the boilerplate, validated at birth with __post_init__ and completed the decision table that 04-06 left open. The end result is Papyrus's definitive catalog: dict[str, Book], normalized key to intelligent object. But this building has a flaw that Ana discovers every night when she shuts down the computer: everything — the catalog, the members, the sale lines — lives in memory and vanishes when the program closes. Tomorrow, catalog is reborn from scratch, with "Faust" once again missing the copies that arrived. Module 6 solves exactly that: files — text, CSV, JSON — so that Papyrus's state survives between runs. Your objects already know how to think; now they'll learn to remember.