Pydantic

Pydantic is the most widely used data validation library for Python. It lets you define data schemas as ordinary Python classes with type hints, then validates, parses, and serializes data against those schemas at runtime, catching malformed input before it reaches your business logic. Its validation engine is implemented in Rust (pydantic-core) and exposed through a pure-Python API, giving it both speed and Python’s usual ergonomics.

It underpins much of the modern Python web and data ecosystem: FastAPI uses it for request/response validation, SQLModel and various ORMs build on it for typed data access, and it’s a common building block wherever untrusted or external data needs to become trustworthy typed objects — API payloads, config files, CLI arguments, and LLM structured outputs.

What You Get

• A BaseModel class that validates and parses data purely from Python type-hint annotations
• A Rust-compiled validation and serialization core (pydantic-core) for near-native performance
• Automatic JSON Schema generation for every model, ready for OpenAPI docs or LLM structured outputs
• TypeAdapter for validating arbitrary types (dataclasses, TypedDicts, lists) without a BaseModel
• Structured, machine-readable validation errors instead of ad hoc exception strings

Common Use Cases

• Validating and parsing incoming API request/response bodies in FastAPI and similar frameworks
• Loading and validating application configuration and environment variables via typed settings models
• Coercing and validating third-party API responses or webhook payloads into typed Python objects
• Defining structured output schemas for LLM function calling and tool use

Under The Hood

Architecture — Pydantic’s core validation and serialization logic is implemented in Rust in the pydantic-core subproject (pydantic-core/src), compiled to a native extension and exposed to Python via PyO3 bindings. The pure-Python pydantic package (pydantic/main.py’s BaseModel, pydantic/fields.py’s FieldInfo) builds a “core schema” description of each model by walking type annotations in pydantic/_internal/_generate_schema.py, which is then handed to pydantic-core to produce a compiled SchemaValidator/SchemaSerializer pair cached on the model class by pydantic/_internal/_model_construction.py’s ModelMetaclass. At runtime, validation and serialization calls go straight into the compiled Rust validators rather than walking Python-level type trees, which is the mechanism behind Pydantic v2’s speed. Generic models, dataclasses, and TypedDicts route through the same schema-generation path (pydantic/_internal/_generics.py, _dataclasses.py), and JSON Schema derivation (pydantic/json_schema.py) works off the same core schema graph.

Tech Stack — A pure-Python 3.10+ layer with three runtime dependencies (typing-extensions, annotated-types, typing-inspection) plus a version-pinned pydantic-core Rust extension (pydantic-core/Cargo.toml) built with PyO3/maturin-style tooling. Development is uv-managed (uv.lock, pyproject.toml dependency-groups) with pytest, pytest-benchmark and pytest-codspeed for performance-regression tracking, and mypy/pyright cross-checks exercised in tests/.

Code Quality — tests/ contains 170+ test files covering validators, serializers, JSON Schema generation, generics, dataclasses, and the mypy plugin. The project uses pytest-examples to execute every documentation code sample as a real test, pytest-benchmark/pytest-codspeed to guard against performance regressions, and a pre-commit config enforcing lint and format on every change. A dedicated deprecated/ subpackage isolates legacy v1-compatible APIs behind explicit deprecation warnings instead of silently changing behavior, and underscore-prefixed _internal/ modules keep the curated public surface (pydantic/init.py, 456 lines of explicit re-exports) distinct from implementation detail.

API Design — The primary API is a single BaseModel subclass with fields expressed as plain Python type hints, so a working model requires no boilerplate beyond annotations. Validators and serializers are opt-in decorators (functional_validators.py, functional_serializers.py) rather than mandatory ceremony, TypeAdapter provides ad hoc validation for non-BaseModel types, and failures (errors.py) return structured, machine-readable ErrorDetails rather than bare strings — a consistently ergonomic design that libraries like FastAPI and SQLModel build directly on top of.