Data Modelling

A function somewhere in your codebase receives {"price": "9,99"} — a string, with a decimal comma, wearing a dict — and nobody notices for three months, because a dict accepts anything and passes it politely along. Three services downstream, something finally does arithmetic on it and the ticket lands on you. The question this track opens with is simple: what type, had you written one, would have refused that value at the front door? The answer is a real record type that knows its own fields — and everything in this track is a step toward objects that reject bad states instead of storing them.

It starts with the daily design decision Python hands you three answers to: a plain class, a dataclass, or a namedtuple for a bundle of data — and when each earns its keep, measured in boilerplate, mutability, and intent. From there, the data model proper: the dunder methods (__repr__, __eq__, __len__ and their relatives) are how you teach your objects Python's own vocabulary, so they print, compare, and iterate like built-ins rather than like opaque handles. This is the layer most self-taught Python stops short of, and it is where "a class I wrote" starts behaving like "a type that belongs in the language".

The last module adds control and permanence. A property turns attribute access into a checkpoint — computed values, validation on set; a descriptor is the reusable machinery behind it, letting one validation rule serve many classes; __slots__ fixes the attribute set and pays you back in memory; and frozen dataclasses make immutability the default rather than a convention. Put together, that is "correct by construction": the "9,99" string never gets in, so no downstream code ever has to wonder. The next track, Protocols & ABCs, writes the contracts these objects satisfy — this one builds objects worth writing contracts for.