GuideBeginner
Python Typing And Pydantic
A type annotation in Python is a label, not a lock: the interpreter reads it, stores it, and keeps running without checking anything. This guide corrects that misunderstanding at the root and builds, on top of it, a complete system of static typing and runtime validation with Pydantic v2. You work through a single realistic case study — Cosecha, a platform that connects small farm producers with restaurants, where every piece of data comes from outside (a messy per-producer CSV, a payments webhook, a weather API, a web form) and none of it can be trusted — and take it from forty unannotated functions to a system where invalid data simply cannot exist. You'll learn to install and read a type checker (mypy) without getting frustrated by the first 300 errors, to describe the real shape of your data with the full `typing` vocabulary, to turn those descriptions into real validation with Pydantic, to express business rules as code instead of scattered `if` statements, and to design boundaries where data gets validated exactly once so the rest of the system can stop defending itself. The guide closes with real-world hard cases — untyped libraries, variable-shape JSON, environment-variable configuration, migrating from Pydantic v1 to v2 — and with an explicit framework for knowing when typing gets in the way and when to concede with a written reason.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Precisely distinguish what a type checker verifies (your code, before running) from what Pydantic verifies (the real data, while the program runs), and why neither replaces the other
- Install and run a type checker (mypy), read its errors without frustration, choose a strictness level, and adopt types incrementally in a large project
- Annotate real code with the full `typing` vocabulary: typed collections, unions, literals and enums, type aliases, generics, and protocols
- Write your first Pydantic v2 model, understand data coercion, and read a complete `ValidationError` with every field that failed
- Express business rules as field and model validators, distinguishing the ones that belong in the model from the ones that depend on external state (database, user, configuration)
- Design a boundary architecture: input, domain, and output models, with immutability and no defensive programming downstream
- Type third-party libraries with no annotations of their own using `.pyi` stub files, and scope `Any` narrowly when data genuinely can't be described
- Use `TypedDict` for dictionaries with a known shape, and type configuration read from environment variables
- Migrate legacy code from Pydantic v1 to v2, recognizing behavior changes, not just method-name changes
- Justify in writing, with engineering judgment, which parts of a system are worth leaving untyped and why
Before you start
What you need to bring
It's for you if...
- Intermediate-level Python developers who already write their own functions and classes but never used a type checker seriously
- Devs who only know Pydantic through FastAPI and want to understand it for what it is: a standalone data modeling and validation library
- Teams receiving unreliable external data (third-party CSVs, webhooks, forms) who need a validation strategy instead of `if` statements scattered through the code
- Anyone migrating a project from Pydantic v1 to v2 who wants to understand the behavior changes, not just do a find-and-replace
- Anyone preparing technical interviews where they're asked about gradual typing, runtime validation, or data-boundary design
Requirements and materials
- Know Python: functions, classes, dictionaries, lists, comprehensions, and having written something bigger than a script
- No prior experience with typing or any type checker is required
- If you're coming from a typed language (Java, C#, TypeScript), keep in mind Python's typing works differently: it's optional and isn't checked at runtime
- No need to know FastAPI, SQLAlchemy, or packaging: those topics live in their own guides
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Module introduction: the founding misunderstanding
- 2. Python doesn't check your types
- 3. The annotation as executable documentation
- 4. Basic types and how to read them
- 5. Annotating functions: parameters and return values
- 6. `None`, `Optional`, and the billion-dollar mistake
- 7. Typing existing code without breaking it
- 8. Project: annotate a module with no types
- 1. Module introduction: who checks the types
- 2. Getting a type checker running
- 3. Reading a type error without frustration
- 4. Strict or lenient: choosing your level
- 5. Adopting types on a large project, incrementally
- 6. `Any`: the escape hatch and its price
- 7. Silencing the checker (and when it's justified)
- 8. Project: get the checker to green
- 1. Module introduction: when basic types aren't enough
- 2. Collections: typed lists, dictionaries, and tuples
- 3. Unions: when something can be two things
- 4. Literals and enumerations: closed values
- 5. Type aliases and named types
- 6. Generics in plain language
- 7. Protocols: typing by behavior
- 8. Project: model the domain with types
- 1. Module introduction: the boundary with the outside world
- 2. Why annotations aren't enough at the boundary
- 3. Your first Pydantic model
- 4. What Pydantic does when data doesn't fit
- 5. Coercion: the conversion that helps and the one that deceives
- 6. Fields: default values, aliases, and constraints
- 7. Nested models and lists of models
- 8. Project: model a real CSV input
- 1. Module introduction: validate once, trust afterward
- 2. The boundary: where dirty data enters
- 3. Input, domain, and output models
- 4. Types that make the invalid state impossible
- 5. Immutability and frozen models
- 6. Dropping defensive programming
- 7. The cost of validating and when it matters
- 8. Project: put validation at the boundary
- 1. Module introduction: where typing gets uncomfortable
- 2. Untyped libraries and `.pyi` files
- 3. Dynamic data that resists typing
- 4. `TypedDict` for shaped dictionaries
- 5. Typed configuration and environment variables
- 6. Migrating from Pydantic v1 to v2
- 7. When typing gets in the way
- 8. Project: tame it without dirtying the code
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!