Pydantic
This section reads Pydantic v2 as a validation engine rather than as a pretty model-declaration library. `BaseModel` is only the visible entry point; the real core is `pydantic-core`, core schema generation, `TypeAdapter`, and the distinction between strict and lax behavior.
Quick takeaway: to understand Pydantic deeply, start with the flow `annotation -> core schema -> validator/serializer -> DTO`. Once that picture is clear, FastAPI integration, settings parsing, and type-driven API design all become easier to reason about.
The Intuition This Part Builds
Look beyond BaseModel
`BaseModel` is great for named contracts, but Pydantic's real scope is wider. `TypeAdapter` lets arbitrary types use the same engine.
Separate strict from lax
Pydantic often defaults to "parse when reasonable." Knowing where to permit coercion and where to reject it is a real API design decision.
Separate validation from serialization
Input rules and output rules are not the same thing. Validators and serializers should not carry the same responsibilities.
See how frameworks consume it
FastAPI reads annotations and turns them into Pydantic-driven request and response boundaries. Typing, runtime introspection, and Pydantic are part of one system.
Recommended Order
Practical Rules
- Do not force every validation problem into a
BaseModel. - Separate public DTOs from internal adapters.
- Choose strict/lax policy per boundary.
- Use validators for input rules and serializers for output contracts.