Pydantic

Also Known As

TL;DR

Explanation

Pydantic V2 (Rust-powered) validates data against type-annotated models. Fields support validators, default values, aliases, and computed properties. BaseModel parses and validates on instantiation — invalid data raises ValidationError with detailed field-level errors. Pydantic is the foundation of FastAPI and is widely used for settings management (BaseSettings), API request/response models, and data pipeline validation.

Common Misconception

Why It Matters

Common Mistakes

• Using Pydantic V1 patterns in V2 — @validator is replaced by @field_validator, class Config by model_config.
• Not using model.model_dump() (V2) vs dict() (V1) — API has changed between versions.
• Expecting Pydantic to validate output, not just input — validation happens at parse time; mutating fields after construction bypasses validators.
• Not using model_config = ConfigDict(strict=True) when coercion should be forbidden — Pydantic coerces '42' to int by default.

Code Examples

# Manual validation — verbose and easy to miss:
def create_user(data: dict) -> dict:
    if not isinstance(data.get('email'), str) or '@' not in data['email']:
        raise ValueError('Invalid email')
    if not isinstance(data.get('age'), int) or data['age'] < 0:
        raise ValueError('Invalid age')
    return {'email': data['email'], 'age': data['age']}

from pydantic import BaseModel, EmailStr, Field

class CreateUserRequest(BaseModel):
    email: EmailStr
    age: int = Field(ge=0, le=150)
    name: str = Field(min_length=1, max_length=100)

# Usage:
try:
    user = CreateUserRequest(**request_data)  # Validates and coerces
except ValidationError as e:
    print(e.errors())  # Detailed field-level errors

References

• ↗ https://docs.pydantic.dev/latest/

Tags

Related Terms