Pydantic, by Running It

About this track

A Python type annotation does nothing at runtime. Write <code>def price(x: int)</code> and Python will hand your function the string "cat" without a word of complaint. Pydantic is the library that makes those annotations real - it reads them, checks the data against them, and tells you precisely what was wrong when it does not fit.

This track works up from a first model to validators, serialisation and schemas. Every idea arrives as a small program you can run and edit on the page, because the fastest way to settle what Pydantic does with a value is to hand it one and look.

Every model on these pages runs in the browser against Pydantic itself, including the ones written to fail - because the error a library gives you is part of learning it, and reading one is a skill the documentation cannot teach.

What you will be able to do

• Describe the shape of incoming data as a model, and let the library reject what does not fit.
• Read a validation error well enough to know which field failed and why.
• Choose between strict and lax coercion deliberately, rather than discovering the default.
• Validate and serialise nested models, custom types, dates and decimals without hand-written checks.
• Recognise the v1 patterns still all over the internet, and their v2 replacements.

How the track is ordered

Models and fields come first, then validation - what happens automatically, what you have to ask for, and how to read the error when it fails. Types follow: nested models, optionals, enums, dates, decimals and the custom types that the standard library does not cover. Then the parts that shape a real application - settings, aliases, serialisation, generics and the FastAPI integration - and finally performance and the v1-to-v2 migration you will meet in existing code.

Where this leads

Pydantic is the validation layer under FastAPI, so the FastAPI track assumes what is here. It is also the boundary layer for anything that reads JSON, environment variables or a config file.