← Pydantic Models & Data Validation

Select a question from the sidebar

18 questions in this topic

Question 1 / 18

How do you create Pydantic models for request validation?

Pydantic models are Python classes that inherit from BaseModel and use type annotations to define fields. FastAPI uses these models to automatically validate request bodies, serialize responses, and generate OpenAPI schemas.

How it works:

Define a class inheriting from BaseModel
Declare fields with type annotations
Use the model as a parameter type in your path operation
FastAPI validates incoming JSON against the model and returns 422 if invalid

Key features:

Automatic type coercion: Pydantic will try to convert compatible types (e.g., "42" to 42 for an int field)
Nested models: Models can reference other models
Default values: Fields with defaults become optional in the request
Validation errors: Automatically returns detailed 422 errors listing every invalid field

Pseudo Code

class ItemCreate(BaseModel):
    name: str
    price: float
    quantity: int = 0  # optional with default

@app.post("/items")
def create_item(item: ItemCreate):
    # item is already validated
    return item

Code

from pydantic import BaseModel
from typing import Optional


class Address(BaseModel):
    street: str
    city: str
    zip_code: str


class UserCreate(BaseModel):
    username: str
    email: str
    age: int
    bio: Optional[str] = None  # optional field
    address: Address            # nested model


# Successful validation
data = {
    "username": "alice",
    "email": "alice@example.com",
    "age": 30,
    "address": {"street": "123 Main St", "city": "Portland", "zip_code": "97201"}
}
user = UserCreate(**data)
print(user.username)
print(user.age)
print(user.address.city)
print(user.bio)

# Type coercion -- string "25" becomes int 25
user2 = UserCreate(
    username="bob", email="bob@example.com", age="25",
    address={"street": "1 Elm", "city": "Salem", "zip_code": "97301"}
)
print(user2.age, type(user2.age))

# Validation error
try:
    bad = UserCreate(username="x", email="x@x.com", age="not_a_number",
                     address={"street": "1", "city": "X", "zip_code": "0"})
except Exception as e:
    print(f"Validation error: {e.error_count()} error(s)")

alice
30
Portland
None
25 <class 'int'>
Validation error: 1 error(s)

Key Points

•Inherit from BaseModel and use type annotations for automatic validation
•Fields without defaults are required; fields with defaults are optional
•Pydantic v2 performs strict or lax type coercion depending on mode
•FastAPI returns 422 Unprocessable Entity with detailed error info on validation failure

Gotchas

•Pydantic v2 does type coercion by default in lax mode -- '42' becomes 42 for int fields which can hide bugs
•Optional[str] = None is not the same as str | None without a default -- the latter is still required
•Model fields are immutable by default in Pydantic v2 unless you set model_config = ConfigDict(frozen=False)

Inherit from BaseModel, add type-annotated fields. FastAPI auto-validates JSON request bodies against the model and returns 422 on failure. Fields with defaults are optional; without defaults are required.

•BaseModel + type annotations = automatic validation
•FastAPI returns 422 with detailed errors on invalid input

from pydantic import BaseModel
from typing import Optional

class UserCreate(BaseModel):
    username: str
    email: str
    age: int
    bio: Optional[str] = None

user = UserCreate(username="alice", email="a@b.com", age=30)
print(user.username, user.age)

alice 30

Pydantic v2 coerces compatible types by default -- '42' silently becomes 42

Question 2 / 18

How does Field() work for adding constraints like min, max, regex, and more?

Field() from Pydantic provides fine-grained control over individual model fields. It supports numeric constraints, string patterns, metadata for docs, and more.

Numeric constraints:

gt, ge, lt, le -- greater/less than (or equal)
multiple_of -- value must be a multiple

String constraints:

min_length, max_length -- length bounds
pattern -- regex the string must match

General:

default -- default value
alias -- accept a different key name in input
title, description -- OpenAPI documentation
examples -- example values for docs
exclude -- exclude from serialization
json_schema_extra -- extra info for generated JSON Schema

Pseudo Code

class Product(BaseModel):
    name: str = Field(min_length=1, max_length=100)
    price: float = Field(gt=0, description="Must be positive")
    sku: str = Field(pattern=r'^[A-Z]{3}-\d{4}$')

Code

from pydantic import BaseModel, Field, ValidationError


class Product(BaseModel):
    name: str = Field(
        min_length=1,
        max_length=100,
        title="Product Name",
        description="Human-readable product name"
    )
    price: float = Field(
        gt=0,
        le=999999.99,
        description="Price must be positive"
    )
    quantity: int = Field(
        default=0,
        ge=0,
        description="Non-negative stock count"
    )
    sku: str = Field(
        pattern=r'^[A-Z]{3}-\d{4}$',
        description="Format: ABC-1234"
    )
    discount: float = Field(
        default=0.0,
        ge=0,
        le=1.0,
        description="Discount as fraction 0.0-1.0"
    )


# Valid product
p = Product(name="Widget", price=29.99, sku="WDG-0001")
print(f"{p.name}: ${p.price}, SKU={p.sku}, qty={p.quantity}")

# Field with alias
class ExternalData(BaseModel):
    user_name: str = Field(alias="userName")
    created_at: str = Field(alias="createdAt")

external = ExternalData(userName="alice", createdAt="2024-01-01")
print(f"{external.user_name} joined {external.created_at}")

# Validation errors from constraints
try:
    Product(name="", price=-5, sku="bad", quantity=-1)
except ValidationError as e:
    for err in e.errors():
        print(f"  {err['loc'][0]}: {err['type']}")

Widget: $29.99, SKU=WDG-0001, qty=0
alice joined 2024-01-01
name: string_too_short
price: greater_than
quantity: greater_than_equal
sku: string_pattern_mismatch

Key Points

•Field() adds numeric constraints (gt, ge, lt, le), string constraints (min_length, max_length, pattern), and metadata
•alias lets you accept different key names from external APIs while using Pythonic names internally
•Constraints generate corresponding JSON Schema rules in the OpenAPI docs automatically
•Use examples parameter for OpenAPI doc examples

Gotchas

•pattern uses Python regex syntax and must match the entire string (anchored automatically in JSON Schema)
•alias fields require the alias name in input by default -- use model_config populate_by_name=True to accept both
•gt means strictly greater than (not equal); ge means greater than or equal

Field() adds constraints to model fields: gt/ge/lt/le for numbers, min_length/max_length/pattern for strings, plus alias, default, and OpenAPI metadata like title and description.

•Field() constrains values and adds OpenAPI metadata

from pydantic import BaseModel, Field

class Product(BaseModel):
    name: str = Field(min_length=1, max_length=100)
    price: float = Field(gt=0)
    sku: str = Field(pattern=r'^[A-Z]{3}-\d{4}$')

p = Product(name="Widget", price=9.99, sku="WDG-0001")
print(p.name, p.price)

Widget 9.99

alias fields only accept the alias key by default, not the Python attribute name

Question 3 / 18

How do field_validator decorators work in Pydantic v2?

field_validator is the Pydantic v2 replacement for the v1 @validator decorator. It validates individual fields with custom logic.

Key differences from v1:

Decorated with @field_validator('field_name') instead of @validator('field_name')
The first argument is cls (it's a classmethod), second is the value
In v1, you got values dict of previously validated fields; in v2 you use model_validator for cross-field access
mode='before' runs before Pydantic's own parsing; mode='after' (default) runs after

Modes:

after (default): Receives the already-parsed and typed value
before: Receives raw input before type coercion -- useful for transforming input
wrap: Receives the value and a handler, giving full control over the validation pipeline

Pseudo Code

@field_validator('field_name', mode='before')
@classmethod
def validate_field(cls, value):
    # transform or validate value
    return transformed_value

Code

from pydantic import BaseModel, field_validator, ValidationError


class User(BaseModel):
    username: str
    email: str
    age: int

    @field_validator('username')
    @classmethod
    def username_must_be_alphanumeric(cls, v: str) -> str:
        if not v.isalnum():
            raise ValueError('must be alphanumeric')
        return v.lower()  # normalize to lowercase

    @field_validator('email')
    @classmethod
    def email_must_contain_at(cls, v: str) -> str:
        if '@' not in v:
            raise ValueError('must contain @')
        return v.lower()

    @field_validator('age')
    @classmethod
    def age_must_be_reasonable(cls, v: int) -> int:
        if not 0 < v < 150:
            raise ValueError('must be between 1 and 149')
        return v


# Valid input -- note username gets lowercased
user = User(username="Alice123", email="ALICE@Example.com", age=30)
print(f"{user.username}, {user.email}, {user.age}")

# mode='before' -- runs before type coercion
class FlexibleInput(BaseModel):
    tags: list[str]

    @field_validator('tags', mode='before')
    @classmethod
    def split_string_tags(cls, v):
        """Accept comma-separated string or list."""
        if isinstance(v, str):
            return [t.strip() for t in v.split(',')]
        return v

from_list = FlexibleInput(tags=["python", "fastapi"])
from_string = FlexibleInput(tags="python, fastapi, pydantic")
print(from_list.tags)
print(from_string.tags)

# Validate multiple fields with one validator
class Config(BaseModel):
    host: str
    backup_host: str

    @field_validator('host', 'backup_host')
    @classmethod
    def must_be_valid_host(cls, v: str) -> str:
        if not v.replace('.', '').replace('-', '').isalnum():
            raise ValueError('invalid hostname characters')
        return v.lower()

c = Config(host="My-Server.Local", backup_host="Backup-01.Local")
print(c.host, c.backup_host)

alice123, alice@example.com, 30
['python', 'fastapi']
['python', 'fastapi', 'pydantic']
my-server.local backup-01.local

Key Points

•field_validator replaces @validator from Pydantic v1
•Must be decorated with both @field_validator and @classmethod
•mode='before' runs before type parsing; mode='after' (default) runs after
•Can validate multiple fields by passing multiple field names to the decorator

Gotchas

•Forgetting @classmethod causes a confusing error in Pydantic v2
•In 'after' mode, the value is already coerced -- raising ValueError for type issues is too late
•field_validator cannot access other fields -- use model_validator for cross-field logic
•Return the value from the validator -- forgetting to return silently sets the field to None

@field_validator('field_name') with @classmethod validates individual fields. Use mode='before' for raw input transformation or mode='after' (default) for typed value validation. Replaces @validator from Pydantic v1.

•Use @field_validator + @classmethod for per-field custom validation

from pydantic import BaseModel, field_validator

class User(BaseModel):
    username: str

    @field_validator('username')
    @classmethod
    def must_be_alpha(cls, v: str) -> str:
        if not v.isalnum():
            raise ValueError('must be alphanumeric')
        return v.lower()

print(User(username="Alice").username)

alice

Always return the value -- forgetting to return sets the field to None

Question 4 / 18

How do model_validator decorators work for cross-field validation?

model_validator validates the entire model after (or before) all individual fields are validated. This is essential for validation rules that depend on multiple fields.

Modes:

mode='after' (default): Receives the fully constructed model instance. You can access all fields via self.
mode='before': Receives the raw input data (usually a dict). Useful for transforming the input shape before field-level validation.
mode='wrap': Receives data and a handler for full pipeline control.

v1 vs v2:

v1 used @root_validator(pre=True/False)
v2 uses @model_validator(mode='before'/'after')

Pseudo Code

@model_validator(mode='after')
def validate_model(self) -> Self:
    if self.field_a > self.field_b:
        raise ValueError('field_a must be <= field_b')
    return self

Code

from pydantic import BaseModel, model_validator, ValidationError
from typing import Self


class DateRange(BaseModel):
    start_date: str
    end_date: str

    @model_validator(mode='after')
    def end_after_start(self) -> Self:
        if self.end_date <= self.start_date:
            raise ValueError('end_date must be after start_date')
        return self


valid = DateRange(start_date="2024-01-01", end_date="2024-12-31")
print(f"{valid.start_date} to {valid.end_date}")

try:
    DateRange(start_date="2024-12-31", end_date="2024-01-01")
except ValidationError as e:
    print(f"Error: {e.errors()[0]['msg']}")


# mode='before' -- transform raw input
class PasswordForm(BaseModel):
    password: str
    confirm_password: str

    @model_validator(mode='before')
    @classmethod
    def check_passwords_match(cls, data: dict) -> dict:
        if isinstance(data, dict):
            pw = data.get('password', '')
            cpw = data.get('confirm_password', '')
            if pw and cpw and pw != cpw:
                raise ValueError('passwords do not match')
        return data

form = PasswordForm(password="secret123", confirm_password="secret123")
print(f"Password set: {len(form.password)} chars")

try:
    PasswordForm(password="abc", confirm_password="xyz")
except ValidationError as e:
    print(f"Error: {e.errors()[0]['msg']}")


# Practical example: shipping cost depends on weight and destination
class ShippingOrder(BaseModel):
    weight_kg: float
    destination: str
    shipping_cost: float

    @model_validator(mode='after')
    def validate_shipping_cost(self) -> Self:
        min_cost = self.weight_kg * 2.0
        if self.destination == 'international':
            min_cost *= 3
        if self.shipping_cost < min_cost:
            raise ValueError(
                f'shipping_cost must be >= {min_cost} for '
                f'{self.weight_kg}kg {self.destination}'
            )
        return self

order = ShippingOrder(weight_kg=5.0, destination="domestic", shipping_cost=15.0)
print(f"Order: {order.weight_kg}kg, ${order.shipping_cost}")

2024-01-01 to 2024-12-31
Error: Value error, end_date must be after start_date
Password set: 9 chars
Error: Value error, passwords do not match
Order: 5.0kg, $15.0

Key Points

•model_validator(mode='after') receives the fully constructed model instance via self
•model_validator(mode='before') receives raw input dict and must be a @classmethod
•Replaces @root_validator from Pydantic v1
•Return self (after mode) or data (before mode) -- forgetting causes validation to fail

Gotchas

•mode='after' is NOT a classmethod -- it receives self; mode='before' IS a classmethod
•In 'before' mode, the data might not be a dict (e.g., if another model is passed), so check isinstance
•model_validator runs after all field_validators in 'after' mode
•Must return Self from 'after' mode or the dict from 'before' mode

@model_validator(mode='after') validates the whole model after all fields are set, accessing fields via self. Use mode='before' with @classmethod for raw input transformation. Replaces @root_validator from v1.

•model_validator validates cross-field logic on the whole model

from pydantic import BaseModel, model_validator
from typing import Self

class DateRange(BaseModel):
    start: str
    end: str

    @model_validator(mode='after')
    def end_after_start(self) -> Self:
        if self.end <= self.start:
            raise ValueError('end must be after start')
        return self

r = DateRange(start="2024-01-01", end="2024-12-31")
print(r.start, r.end)

2024-01-01 2024-12-31

mode='after' uses self (not classmethod); mode='before' uses cls + @classmethod

Question 5 / 18

How do you handle nested Pydantic models?

Pydantic supports nested models where a field's type is another BaseModel. This allows you to validate complex, deeply structured JSON in a type-safe way.

How it works:

Define separate models for each logical unit
Use one model as a field type in another
Pydantic recursively validates the entire structure
Lists of models: list[ChildModel]
Optional nested: Optional[ChildModel] = None

Benefits:

Reusability: Same model used in multiple parent models
Separation of concerns: Each model handles its own validation
Automatic recursion: Nested dicts are automatically parsed into nested model instances
OpenAPI generation: FastAPI generates nested JSON Schema automatically

Pseudo Code

class Address(BaseModel):
    city: str
    zip_code: str

class User(BaseModel):
    name: str
    address: Address             # nested model
    tags: list[Tag]              # list of nested models
    backup: Optional[Address]    # optional nested

Code

from pydantic import BaseModel, Field
from typing import Optional


class Address(BaseModel):
    street: str
    city: str
    state: str = Field(min_length=2, max_length=2)
    zip_code: str = Field(pattern=r'^\d{5}$')


class ContactInfo(BaseModel):
    email: str
    phone: Optional[str] = None


class OrderItem(BaseModel):
    product_name: str
    quantity: int = Field(gt=0)
    unit_price: float = Field(gt=0)


class Order(BaseModel):
    order_id: str
    customer_name: str
    contact: ContactInfo
    shipping_address: Address
    billing_address: Optional[Address] = None  # optional nested
    items: list[OrderItem] = Field(min_length=1)  # must have at least 1 item


# Pydantic parses nested dicts into model instances automatically
data = {
    "order_id": "ORD-001",
    "customer_name": "Alice",
    "contact": {"email": "alice@example.com", "phone": "555-0100"},
    "shipping_address": {
        "street": "123 Main St", "city": "Portland",
        "state": "OR", "zip_code": "97201"
    },
    "items": [
        {"product_name": "Widget", "quantity": 2, "unit_price": 9.99},
        {"product_name": "Gadget", "quantity": 1, "unit_price": 24.99}
    ]
}

order = Order(**data)
print(f"Order {order.order_id} for {order.customer_name}")
print(f"Ship to: {order.shipping_address.city}, {order.shipping_address.state}")
print(f"Contact: {order.contact.email}")
print(f"Items: {len(order.items)}")
for item in order.items:
    print(f"  - {item.product_name}: {item.quantity} x ${item.unit_price}")
print(f"Billing address: {order.billing_address}")

Order ORD-001 for Alice
Ship to: Portland, OR
Contact: alice@example.com
Items: 2
- Widget: 2 x $9.99
- Gadget: 1 x $24.99
Billing address: None

Key Points

•Use another BaseModel as a field type for nested validation
•Pydantic recursively validates nested dicts into model instances
•list[Model] validates a list of nested models with individual element validation
•Optional[Model] = None makes nested models optional

Gotchas

•Validation errors for nested models show dot-notation paths like 'address.zip_code'
•Passing a model instance vs a dict both work, but model instances skip re-validation in v2 by default
•Deeply nested models can make 422 error responses hard to read for API consumers

Use a BaseModel as a field type to nest models. Pydantic recursively validates nested dicts. Use list[Model] for lists and Optional[Model] = None for optional nested objects.

•Nested dicts are automatically parsed into nested model instances

from pydantic import BaseModel

class Address(BaseModel):
    city: str
    zip_code: str

class User(BaseModel):
    name: str
    address: Address

user = User(name="Alice", address={"city": "Portland", "zip_code": "97201"})
print(user.address.city)

Portland

Nested validation errors use dot-notation paths like 'address.zip_code'

Question 6 / 18

What is the difference between Optional fields and required fields?

In Pydantic v2, whether a field is required or optional depends on whether it has a default value, not just its type annotation.

Rules:

Declaration	Required?	Accepts None?
`name: str`	Yes	No
`name: str = "default"`	No	No
`name: Optional[str]` (or `str \\| None`)	Yes	Yes
`name: Optional[str] = None`	No	Yes

Key distinction:

Required = must be provided in the input
Optional = can be omitted (uses default)
Nullable = can be explicitly set to None

These are independent concepts! A field can be required AND nullable (str | None without a default).

Pseudo Code

class Example(BaseModel):
    required: str                       # must provide, can't be None
    with_default: str = "hi"            # can omit, uses default
    nullable_required: str | None       # must provide, can be None
    nullable_optional: str | None = None  # can omit, defaults to None

Code

from pydantic import BaseModel, ValidationError
from typing import Optional


class UserProfile(BaseModel):
    # Required, not nullable
    username: str

    # Optional (has default), not nullable
    role: str = "viewer"

    # Required AND nullable -- must be in payload but can be None
    middle_name: str | None

    # Optional AND nullable -- can be omitted, defaults to None
    bio: Optional[str] = None


# All fields provided
u1 = UserProfile(
    username="alice", middle_name="Marie", bio="Developer"
)
print(f"{u1.username}, role={u1.role}, middle={u1.middle_name}, bio={u1.bio}")

# Omitting optional fields
u2 = UserProfile(username="bob", middle_name=None)
print(f"{u2.username}, role={u2.role}, middle={u2.middle_name}, bio={u2.bio}")

# middle_name is required even though it's nullable
try:
    UserProfile(username="charlie")
except ValidationError as e:
    print(f"Missing required field: {e.errors()[0]['loc']}")

# username cannot be None
try:
    UserProfile(username=None, middle_name=None)
except ValidationError as e:
    print(f"Not nullable: {e.errors()[0]['loc']}: {e.errors()[0]['type']}")

alice, role=viewer, middle=Marie, bio=Developer
bob, role=viewer, middle=None, bio=None
Missing required field: ('middle_name',)
Not nullable: ('username',): string_type

Key Points

•Required vs optional depends on having a default value, not the type
•str | None without a default is REQUIRED but NULLABLE
•Optional[str] = None is both optional and nullable
•Pydantic v2 distinguishes 'missing' from 'null' in validation errors

Gotchas

•Optional[str] WITHOUT a default is still required in Pydantic v2 -- this surprises many developers
•In FastAPI, omitted optional fields are not included in the request JSON, but fields set to null explicitly are
•Using str | None syntax requires Python 3.10+ in annotations (or from __future__ import annotations)

A field is required if it has no default value. Optional[str] (= str | None) without a default is required but nullable. Add = None to make it truly optional. Required vs nullable are independent concepts.

•Default value controls required vs optional; type controls nullable

from pydantic import BaseModel

class User(BaseModel):
    name: str                        # required, not nullable
    bio: str | None = None           # optional and nullable
    middle: str | None               # required but nullable

u = User(name="Alice", middle=None)
print(u.name, u.middle, u.bio)

Alice None None

Optional[str] without a default is required -- the name 'Optional' is misleading

Question 7 / 18

How does model_dump() work and what replaced .dict()?

model_dump() is the Pydantic v2 replacement for .dict(). It converts a model instance to a Python dictionary with several powerful filtering options.

Key parameters:

include / exclude -- set of field names to include or exclude
exclude_unset -- omit fields not explicitly set (useful for PATCH operations)
exclude_defaults -- omit fields that equal their default value
exclude_none -- omit fields that are None
by_alias -- use alias names as keys instead of Python attribute names
mode -- 'python' (default) returns Python objects; 'json' returns JSON-compatible types

Migration from v1:

.dict() -> model_dump()
.json() -> model_dump_json()
.parse_obj() -> model_validate()
.parse_raw() -> model_validate_json()

Pseudo Code

instance = MyModel(field_a="x", field_b=None)

instance.model_dump()                    # all fields as dict
instance.model_dump(exclude_none=True)   # skip None fields
instance.model_dump(exclude_unset=True)  # skip fields not explicitly set
instance.model_dump(include={'field_a'}) # only specified fields

Code

from pydantic import BaseModel, Field
from typing import Optional


class UserUpdate(BaseModel):
    username: Optional[str] = None
    email: Optional[str] = None
    bio: Optional[str] = None
    role: str = "viewer"


# Only set some fields (simulating a PATCH request)
update = UserUpdate(email="new@example.com")

print("Full dump:")
print(update.model_dump())

print("\nexclude_unset (only explicitly set fields):")
print(update.model_dump(exclude_unset=True))

print("\nexclude_none:")
print(update.model_dump(exclude_none=True))

print("\nexclude_defaults:")
print(update.model_dump(exclude_defaults=True))

# include/exclude specific fields
class Product(BaseModel):
    name: str
    price: float
    internal_sku: str
    secret_cost: float

p = Product(name="Widget", price=9.99, internal_sku="W001", secret_cost=3.50)

print("\nExclude internal fields:")
print(p.model_dump(exclude={'internal_sku', 'secret_cost'}))

print("\nInclude only public fields:")
print(p.model_dump(include={'name', 'price'}))

# by_alias
class APIResponse(BaseModel):
    user_name: str = Field(alias="userName")
    created_at: str = Field(alias="createdAt")

    model_config = {"populate_by_name": True}

resp = APIResponse(user_name="alice", created_at="2024-01-01")
print("\nBy Python name:", resp.model_dump())
print("By alias:", resp.model_dump(by_alias=True))

Full dump:
{'username': None, 'email': 'new@example.com', 'bio': None, 'role': 'viewer'}

exclude_unset (only explicitly set fields):
{'email': 'new@example.com'}

exclude_none:
{'email': 'new@example.com', 'role': 'viewer'}

exclude_defaults:
{'email': 'new@example.com'}

Exclude internal fields:
{'name': 'Widget', 'price': 9.99}

Include only public fields:
{'name': 'Widget', 'price': 9.99}

By Python name: {'user_name': 'alice', 'created_at': '2024-01-01'}
By alias: {'userName': 'alice', 'createdAt': '2024-01-01'}

Key Points

•model_dump() replaces .dict() in Pydantic v2
•exclude_unset=True is essential for PATCH operations -- only updates explicitly provided fields
•include/exclude filter which fields appear in the output dict
•by_alias=True uses Field alias names as dict keys

Gotchas

•.dict() still works in Pydantic v2 but emits a deprecation warning
•exclude_unset vs exclude_none: a field explicitly set to None is 'set' but None
•include and exclude cannot both be used on the same field -- include takes priority
•Nested models are also converted to dicts recursively by default

model_dump() replaces .dict() in Pydantic v2. Key params: exclude_unset=True for PATCH updates, exclude_none=True, include/exclude sets, and by_alias=True for alias keys.

•model_dump(exclude_unset=True) is essential for PATCH operations

from pydantic import BaseModel
from typing import Optional

class UserUpdate(BaseModel):
    name: Optional[str] = None
    email: Optional[str] = None

update = UserUpdate(email="new@test.com")
print(update.model_dump(exclude_unset=True))

{'email': 'new@test.com'}

exclude_unset and exclude_none behave differently -- explicitly set None is 'set'

Question 8 / 18

What are the key Pydantic v2 migration changes from v1?

Pydantic v2 is a ground-up rewrite with a Rust-powered core (pydantic-core) that brings 5-50x performance improvements but introduces significant API changes.

Major renames:

v1	v2
`.dict()`	`model_dump()`
`.json()`	`model_dump_json()`
`.parse_obj(data)`	`model_validate(data)`
`.parse_raw(json_str)`	`model_validate_json(json_str)`
`.schema()`	`model_json_schema()`
`.copy(update={})`	`model_copy(update={})`
`@validator`	`@field_validator`
`@root_validator`	`@model_validator`
`class Config:`	`model_config = ConfigDict(...)`
`Config.orm_mode = True`	`model_config = ConfigDict(from_attributes=True)`
`Field(regex=...)`	`Field(pattern=...)`

Behavioral changes:

Strict mode: Optional strict validation (no type coercion)
Validators: @field_validator requires @classmethod; @model_validator(mode='after') uses self not cls, values
Generic models: Better support with standard Python generics
Performance: 5-50x faster due to Rust core
Error messages: More structured, machine-readable error format

Pseudo Code

# v1 style (deprecated):
class Model(BaseModel):
    class Config:
        orm_mode = True
    @validator('field')
    def check(cls, v): ...

# v2 style:
class Model(BaseModel):
    model_config = ConfigDict(from_attributes=True)
    @field_validator('field')
    @classmethod
    def check(cls, v): ...

Code

from pydantic import BaseModel, ConfigDict, field_validator, model_validator
from typing import Self


# Pydantic v2 model with all modern patterns
class User(BaseModel):
    # model_config replaces class Config
    model_config = ConfigDict(
        from_attributes=True,     # was orm_mode
        populate_by_name=True,    # was allow_population_by_field_name
        str_strip_whitespace=True,
        strict=False,             # allow type coercion (default)
    )

    username: str
    email: str
    age: int

    # field_validator replaces @validator
    @field_validator('email')
    @classmethod
    def validate_email(cls, v: str) -> str:
        if '@' not in v:
            raise ValueError('invalid email')
        return v.lower()

    # model_validator replaces @root_validator
    @model_validator(mode='after')
    def check_username_not_email(self) -> Self:
        if '@' in self.username:
            raise ValueError('username cannot be an email')
        return self


user = User(username="alice", email="ALICE@test.com", age=30)

# model_dump() replaces .dict()
print("model_dump:", user.model_dump())

# model_dump_json() replaces .json()
print("model_dump_json:", user.model_dump_json())

# model_validate() replaces .parse_obj()
user2 = User.model_validate({"username": "bob", "email": "bob@x.com", "age": 25})
print("model_validate:", user2.username)

# model_json_schema() replaces .schema()
schema = User.model_json_schema()
print("Schema title:", schema['title'])
print("Required fields:", schema['required'])

# model_copy() replaces .copy()
user3 = user.model_copy(update={"username": "alice_v2"})
print("model_copy:", user3.username, user3.email)

# from_attributes (was orm_mode) -- works with any object with attributes
class FakeORM:
    username = "from_orm"
    email = "orm@test.com"
    age = 40

user4 = User.model_validate(FakeORM())
print("from_attributes:", user4.username)

model_dump: {'username': 'alice', 'email': 'alice@test.com', 'age': 30}
model_dump_json: {"username":"alice","email":"alice@test.com","age":30}
model_validate: bob
Schema title: User
Required fields: ['username', 'email', 'age']
model_copy: alice_v2 alice@test.com
from_attributes: from_orm

Key Points

•All method names changed: .dict() -> model_dump(), .json() -> model_dump_json(), etc.
•class Config replaced by model_config = ConfigDict(...)
•@validator -> @field_validator (must add @classmethod); @root_validator -> @model_validator
•Rust core gives 5-50x performance improvement

Gotchas

•v1 methods still exist but emit DeprecationWarning -- code will break in v3
•orm_mode renamed to from_attributes in ConfigDict
•field_validator requires @classmethod decorator which v1's @validator did not
•model_validator(mode='after') uses self, not (cls, values) like root_validator(pre=False)

Pydantic v2 renames all APIs: .dict() -> model_dump(), @validator -> @field_validator + @classmethod, class Config -> model_config = ConfigDict(...), orm_mode -> from_attributes. Built on Rust for 5-50x speed.

•All v1 methods renamed with model_ prefix; class Config replaced by model_config dict

from pydantic import BaseModel, ConfigDict, field_validator

class User(BaseModel):
    model_config = ConfigDict(from_attributes=True)
    name: str

    @field_validator('name')
    @classmethod
    def lowercase(cls, v: str) -> str:
        return v.lower()

u = User(name="ALICE")
print(u.model_dump())

{'name': 'alice'}

field_validator now requires @classmethod -- forgetting it causes an error in v2

Question 9 / 18

How do you use model_config instead of class Config?

In Pydantic v2, the inner class Config is replaced by a model_config class variable set to a ConfigDict(...) call. This provides better IDE support, type checking, and is the only way to configure models going forward.

Common settings:

strict -- Disable type coercion (default False)
from_attributes -- Read data from object attributes like ORM objects (was orm_mode)
populate_by_name -- Accept both Python name and alias (was allow_population_by_field_name)
str_strip_whitespace -- Strip whitespace from strings
str_to_lower / str_to_upper -- Case normalization
frozen -- Make instances immutable (was allow_mutation = False)
extra -- 'forbid', 'allow', or 'ignore' extra fields
json_schema_extra -- Add extra info to generated JSON Schema
use_enum_values -- Store enum value instead of enum member
validate_default -- Run validators on default values too

Pseudo Code

# v1 (deprecated):
class Model(BaseModel):
    class Config:
        orm_mode = True
        allow_mutation = False

# v2 (current):
class Model(BaseModel):
    model_config = ConfigDict(
        from_attributes=True,
        frozen=True,
    )

Code

from pydantic import BaseModel, ConfigDict, Field


# Strict mode -- no type coercion
class StrictUser(BaseModel):
    model_config = ConfigDict(strict=True)
    name: str
    age: int

try:
    StrictUser(name="alice", age="30")  # string won't coerce to int
except Exception as e:
    print(f"Strict mode: {e.errors()[0]['type']}")


# Frozen model (immutable)
class ImmutablePoint(BaseModel):
    model_config = ConfigDict(frozen=True)
    x: float
    y: float

point = ImmutablePoint(x=1.0, y=2.0)
try:
    point.x = 5.0
except Exception as e:
    print(f"Frozen: {type(e).__name__}")


# Extra fields handling
class StrictSchema(BaseModel):
    model_config = ConfigDict(extra='forbid')
    name: str

try:
    StrictSchema(name="alice", unknown_field="oops")
except Exception as e:
    print(f"Extra forbid: {e.errors()[0]['type']}")


# String preprocessing
class CleanInput(BaseModel):
    model_config = ConfigDict(
        str_strip_whitespace=True,
        str_to_lower=True,
    )
    username: str
    email: str

clean = CleanInput(username="  ALICE  ", email="  ALICE@Test.Com  ")
print(f"Cleaned: '{clean.username}', '{clean.email}'")


# from_attributes (ORM mode)
class UserOut(BaseModel):
    model_config = ConfigDict(from_attributes=True)
    id: int
    name: str

class FakeDBRow:
    def __init__(self, id, name):
        self.id = id
        self.name = name

row = FakeDBRow(id=1, name="alice")
user = UserOut.model_validate(row)
print(f"From ORM: id={user.id}, name={user.name}")


# json_schema_extra for OpenAPI docs
class Item(BaseModel):
    model_config = ConfigDict(
        json_schema_extra={
            "examples": [
                {"name": "Widget", "price": 9.99}
            ]
        }
    )
    name: str
    price: float

schema = Item.model_json_schema()
print(f"Schema examples: {schema.get('examples')}")

Strict mode: int_type
Frozen: ValidationError
Extra forbid: extra_forbidden
Cleaned: 'alice', 'alice@test.com'
From ORM: id=1, name=alice
Schema examples: [{'name': 'Widget', 'price': 9.99}]

Key Points

•model_config = ConfigDict(...) replaces class Config in Pydantic v2
•ConfigDict is a TypedDict providing full IDE autocomplete and type checking
•from_attributes=True replaces orm_mode=True for ORM object reading
•extra='forbid' rejects unknown fields -- important for strict API contracts

Gotchas

•class Config still works in v2 but will be removed in v3
•frozen=True replaces allow_mutation=False and uses a different error type (ValidationError not TypeError)
•str_strip_whitespace and str_to_lower apply to ALL string fields -- use field_validator for selective processing
•populate_by_name must be True to accept both alias and Python field name

model_config = ConfigDict(...) replaces class Config. Common settings: from_attributes=True (ORM mode), frozen=True (immutable), extra='forbid' (reject unknown fields), str_strip_whitespace=True.

•ConfigDict provides typed, IDE-friendly configuration replacing class Config

from pydantic import BaseModel, ConfigDict

class User(BaseModel):
    model_config = ConfigDict(
        from_attributes=True,
        extra='forbid',
        str_strip_whitespace=True,
    )
    name: str
    email: str

user = User(name="  Alice  ", email="  a@b.com  ")
print(user.name, user.email)

Alice a@b.com

str_strip_whitespace applies to ALL string fields, not selectively

Question 10 / 18

How do you use BaseSettings for configuration management?

BaseSettings from pydantic-settings (separate package in v2) reads configuration from environment variables, .env files, and other sources, with full Pydantic validation.

How it works:

Define a class inheriting from BaseSettings
Each field is read from an environment variable (case-insensitive by default)
Sources are checked in priority order: init kwargs > env vars > .env file > defaults
All Pydantic validation applies (types, constraints, validators)

Installation:

pip install pydantic-settings

Key features:

env_prefix -- prefix all env var names (e.g., APP_ prefix means APP_DATABASE_URL)
env_file -- read from .env file
env_nested_delimiter -- parse nested objects from env vars
Secrets directory support for Docker/Kubernetes secrets

Pseudo Code

class Settings(BaseSettings):
    model_config = SettingsConfigDict(
        env_prefix='APP_',
        env_file='.env',
    )
    database_url: str
    debug: bool = False

settings = Settings()  # reads from env vars

Code

from pydantic_settings import BaseSettings, SettingsConfigDict
from pydantic import Field
import os


# Simulate environment variables
os.environ['APP_DATABASE_URL'] = 'postgresql://localhost/mydb'
os.environ['APP_SECRET_KEY'] = 'super-secret-key-123'
os.environ['APP_DEBUG'] = 'true'
os.environ['APP_MAX_CONNECTIONS'] = '50'


class Settings(BaseSettings):
    model_config = SettingsConfigDict(
        env_prefix='APP_',       # all vars prefixed with APP_
        env_file='.env',         # also read from .env file
        env_file_encoding='utf-8',
        case_sensitive=False,    # APP_DEBUG and app_debug both work
    )

    database_url: str
    secret_key: str
    debug: bool = False
    max_connections: int = Field(default=10, ge=1, le=1000)
    app_name: str = "MyApp"


settings = Settings()
print(f"DB: {settings.database_url}")
print(f"Debug: {settings.debug}")
print(f"Max connections: {settings.max_connections}")
print(f"App: {settings.app_name}")

# Use as FastAPI dependency
# from functools import lru_cache
# @lru_cache
# def get_settings():
#     return Settings()
#
# @app.get("/info")
# def info(settings: Annotated[Settings, Depends(get_settings)]):
#     return {"app": settings.app_name, "debug": settings.debug}

# Cleanup
for key in ['APP_DATABASE_URL', 'APP_SECRET_KEY', 'APP_DEBUG', 'APP_MAX_CONNECTIONS']:
    os.environ.pop(key, None)

DB: postgresql://localhost/mydb
Debug: True
Max connections: 50
App: MyApp

Key Points

•BaseSettings lives in pydantic-settings package (separate install in v2)
•Fields are read from env vars, .env files, or defaults with full validation
•env_prefix adds a prefix to all env var names for namespacing
•Use @lru_cache or functools.cache on the settings factory to avoid re-reading env on every request

Gotchas

•pydantic-settings is a separate package in v2 -- pip install pydantic-settings
•SettingsConfigDict (not ConfigDict) is used for BaseSettings configuration
•Priority order: init args > env vars > .env file > defaults -- env vars override .env file
•env_prefix is case-insensitive by default so APP_DB_URL and app_db_url both match

BaseSettings from pydantic-settings reads config from env vars and .env files with validation. Use env_prefix for namespacing. Cache with @lru_cache in FastAPI.

•Separate package: pip install pydantic-settings

from pydantic_settings import BaseSettings, SettingsConfigDict
import os

os.environ['APP_DB'] = 'sqlite:///app.db'

class Settings(BaseSettings):
    model_config = SettingsConfigDict(env_prefix='APP_')
    db: str
    debug: bool = False

s = Settings()
print(s.db, s.debug)
os.environ.pop('APP_DB')

sqlite:///app.db False

Env vars override .env file values -- priority matters

Question 11 / 18

How do discriminated unions work in Pydantic?

Discriminated unions (tagged unions) let Pydantic efficiently pick the right model from a Union type based on a discriminator field -- a field whose literal value identifies the variant.

Why use them:

Without a discriminator, Pydantic tries each union member in order until one validates -- slow and ambiguous
With a discriminator, Pydantic checks the tag field first and directly validates against the correct model -- O(1) lookup

How to define:

Each model in the union has a Literal field with a unique value
Use Discriminator('field_name') or Field(discriminator='field_name') to tell Pydantic which field is the tag

Use cases:

Notifications: email vs SMS vs push with different fields
Payments: credit card vs bank transfer vs PayPal
Events: different event types in a stream

Pseudo Code

class Email(BaseModel):
    type: Literal['email']
    address: str

class SMS(BaseModel):
    type: Literal['sms']
    phone: str

class Parent(BaseModel):
    notification: Email | SMS = Field(discriminator='type')

Code

from pydantic import BaseModel, Field
from typing import Literal, Union, Annotated
from pydantic import Discriminator


# Define variants with Literal discriminator field
class CreditCardPayment(BaseModel):
    method: Literal['credit_card']
    card_number: str
    expiry: str
    cvv: str


class BankTransferPayment(BaseModel):
    method: Literal['bank_transfer']
    account_number: str
    routing_number: str


class PayPalPayment(BaseModel):
    method: Literal['paypal']
    paypal_email: str


# Using Field(discriminator=...) in a parent model
PaymentUnion = Union[CreditCardPayment, BankTransferPayment, PayPalPayment]

class Order(BaseModel):
    order_id: str
    amount: float
    payment: PaymentUnion = Field(discriminator='method')


# Pydantic checks 'method' field to pick the right model
cc_order = Order(
    order_id="O-001", amount=99.99,
    payment={"method": "credit_card", "card_number": "4111", "expiry": "12/25", "cvv": "123"}
)
print(f"Order {cc_order.order_id}: {type(cc_order.payment).__name__}")

pp_order = Order(
    order_id="O-002", amount=49.99,
    payment={"method": "paypal", "paypal_email": "alice@paypal.com"}
)
print(f"Order {pp_order.order_id}: {type(pp_order.payment).__name__}")

# Using Annotated + Discriminator for standalone union types
Notification = Annotated[
    Union[CreditCardPayment, BankTransferPayment, PayPalPayment],
    Discriminator('method')
]

# Validation error with unknown discriminator value
from pydantic import ValidationError
try:
    Order(order_id="O-003", amount=10.0,
          payment={"method": "bitcoin", "wallet": "abc"})
except ValidationError as e:
    print(f"Error: {e.errors()[0]['type']}")

Order O-001: CreditCardPayment
Order O-002: PayPalPayment
Error: union_tag_invalid

Key Points

•Each variant has a Literal field whose value uniquely identifies it
•Field(discriminator='field_name') enables O(1) model selection instead of try-each
•Pydantic generates proper oneOf JSON Schema with discriminator mapping for OpenAPI
•Can also use Annotated[Union[...], Discriminator('field')] for standalone types

Gotchas

•All union members must have the discriminator field with a Literal type
•Discriminator field values must be unique across all variants
•Without a discriminator, Pydantic validates against each member in order -- first match wins which may be wrong
•The discriminator field must be required (no default) on each variant

Discriminated unions use a Literal field as a tag to pick the right model from a Union. Use Field(discriminator='field_name') for O(1) model selection instead of trial-and-error matching.

•Literal field + discriminator enables efficient tagged union matching

from pydantic import BaseModel, Field
from typing import Literal, Union

class Cat(BaseModel):
    pet_type: Literal['cat']
    meow_volume: int

class Dog(BaseModel):
    pet_type: Literal['dog']
    bark_volume: int

class Owner(BaseModel):
    pet: Union[Cat, Dog] = Field(discriminator='pet_type')

o = Owner(pet={"pet_type": "cat", "meow_volume": 5})
print(type(o.pet).__name__)

Cat

All variants must have the discriminator field with unique Literal values

Question 12 / 18

How do you create custom types with Pydantic?

Pydantic v2 offers several ways to create reusable custom types that encapsulate validation logic.

Approaches:

Annotated + AfterValidator/BeforeValidator -- Simplest approach, wraps validation around existing types
Custom class with __get_pydantic_core_schema__ -- Full control, integrates with pydantic-core
TypeAdapter -- Validate any type outside of a model
Constrained types with Annotated -- Combine Field-like constraints with Annotated

Best practices:

Use Annotated with validators for simple cases
Create a proper type class only when you need custom serialization or complex logic
TypeAdapter is useful for validating standalone values without a model

Pseudo Code

from pydantic import AfterValidator
from typing import Annotated

def validate_positive(v: int) -> int:
    assert v > 0
    return v

PositiveInt = Annotated[int, AfterValidator(validate_positive)]

Code

from pydantic import BaseModel, AfterValidator, BeforeValidator, TypeAdapter
from pydantic import Field
from typing import Annotated
import re


# Approach 1: Annotated + AfterValidator (most common)
def validate_email(v: str) -> str:
    if not re.match(r'^[\w.-]+@[\w.-]+\.\w+$', v):
        raise ValueError('invalid email format')
    return v.lower()

EmailStr = Annotated[str, AfterValidator(validate_email)]


# Annotated + BeforeValidator for input transformation
def comma_separated_to_list(v) -> list[str]:
    if isinstance(v, str):
        return [s.strip() for s in v.split(',') if s.strip()]
    return v

CommaSeparatedList = Annotated[list[str], BeforeValidator(comma_separated_to_list)]


# Combine multiple validators
def strip_whitespace(v: str) -> str:
    return v.strip()

def must_not_be_empty(v: str) -> str:
    if not v:
        raise ValueError('must not be empty')
    return v

NonEmptyStr = Annotated[str, AfterValidator(strip_whitespace), AfterValidator(must_not_be_empty)]


# Use custom types in a model
class UserCreate(BaseModel):
    name: NonEmptyStr
    email: EmailStr
    tags: CommaSeparatedList = []


user = UserCreate(name="  Alice  ", email="ALICE@Test.Com", tags="python, fastapi, pydantic")
print(f"Name: '{user.name}'")
print(f"Email: {user.email}")
print(f"Tags: {user.tags}")

# TypeAdapter for validating without a model
adapter = TypeAdapter(list[EmailStr])
emails = adapter.validate_python(["A@B.com", "C@D.com"])
print(f"Validated emails: {emails}")

Name: 'Alice'
Email: alice@test.com
Tags: ['python', 'fastapi', 'pydantic']
Validated emails: ['a@b.com', 'c@d.com']

Key Points

•Annotated[type, AfterValidator(fn)] is the simplest way to create reusable custom types
•BeforeValidator runs before type coercion; AfterValidator runs after
•Multiple validators can be chained in a single Annotated type
•TypeAdapter validates standalone values without needing a full model

Gotchas

•AfterValidator receives the already-coerced value; BeforeValidator gets raw input
•Validators in Annotated run left to right -- order matters for chained validators
•TypeAdapter.validate_python() creates new objects each call -- cache if performance matters
•Custom types must be serializable if used in FastAPI response models

Use Annotated[type, AfterValidator(fn)] for reusable validated types. BeforeValidator transforms raw input, AfterValidator validates after coercion. TypeAdapter validates values outside of models.

•Annotated + AfterValidator creates reusable validated types

from pydantic import BaseModel, AfterValidator
from typing import Annotated

def check_positive(v: int) -> int:
    if v <= 0:
        raise ValueError('must be positive')
    return v

PositiveInt = Annotated[int, AfterValidator(check_positive)]

class Item(BaseModel):
    quantity: PositiveInt

print(Item(quantity=5).quantity)

Validators in Annotated run left to right -- order matters

Question 13 / 18

How does JSON Schema generation work with Pydantic models?

Pydantic models automatically generate JSON Schema (Draft 2020-12), which FastAPI uses to build its OpenAPI documentation (Swagger UI and ReDoc).

How it works:

model_json_schema() returns a dict representing the JSON Schema
Field types map to JSON Schema types (str -> string, int -> integer, etc.)
Field() constraints become JSON Schema constraints (min_length, maximum, pattern, etc.)
Nested models create $defs references
title, description, and examples from Field() appear in the schema

Customization:

json_schema_extra in model_config adds arbitrary schema properties
Field(json_schema_extra={...}) adds per-field schema properties
Custom types can define __get_pydantic_json_schema__ for custom schema generation

Pseudo Code

class MyModel(BaseModel):
    name: str = Field(description="User's name")
    age: int = Field(ge=0, le=150)

schema = MyModel.model_json_schema()
# Produces JSON Schema with type, constraints, description

Code

from pydantic import BaseModel, Field
from typing import Optional
import json


class Address(BaseModel):
    street: str = Field(description="Street address")
    city: str
    zip_code: str = Field(pattern=r'^\d{5}$')


class UserCreate(BaseModel):
    """Schema for creating a new user."""
    model_config = {
        "json_schema_extra": {
            "examples": [
                {
                    "username": "alice",
                    "email": "alice@example.com",
                    "age": 30,
                    "address": {"street": "123 Main", "city": "Portland", "zip_code": "97201"}
                }
            ]
        }
    }

    username: str = Field(min_length=3, max_length=50, description="Unique username")
    email: str = Field(description="Valid email address")
    age: int = Field(ge=0, le=150, description="Age in years")
    bio: Optional[str] = Field(default=None, max_length=500)
    address: Address


schema = UserCreate.model_json_schema()
print(json.dumps(schema, indent=2))

{
"$defs": {
"Address": {
"properties": {
"street": {
"description": "Street address",
"title": "Street",
"type": "string"
},
"city": {
"title": "City",
"type": "string"
},
"zip_code": {
"pattern": "^\\d{5}$",
"title": "Zip Code",
"type": "string"
}
},
"required": ["street", "city", "zip_code"],
"title": "Address",
"type": "object"
}
},
"description": "Schema for creating a new user.",
"examples": [
{
"username": "alice",
"email": "alice@example.com",
"age": 30,
"address": {"street": "123 Main", "city": "Portland", "zip_code": "97201"}
}
],
"properties": {
"username": {
"description": "Unique username",
"maxLength": 50,
"minLength": 3,
"title": "Username",
"type": "string"
},
"email": {
"description": "Valid email address",
"title": "Email",
"type": "string"
},
"age": {
"description": "Age in years",
"maximum": 150,
"minimum": 0,
"title": "Age",
"type": "integer"
},
"bio": {
"anyOf": [{"maxLength": 500, "type": "string"}, {"type": "null"}],
"default": null,
"title": "Bio"
},
"address": {"$ref": "#/$defs/Address"}
},
"required": ["username", "email", "age", "address"],
"title": "UserCreate",
"type": "object"
}

Key Points

•model_json_schema() generates JSON Schema that FastAPI uses for OpenAPI docs
•Field constraints (min_length, ge, pattern) map directly to JSON Schema keywords
•Nested models create $defs references avoiding schema duplication
•json_schema_extra adds custom properties like examples for Swagger UI

Gotchas

•Optional fields with defaults show as anyOf with null type in the schema
•Custom validators do not automatically appear in the JSON Schema -- add constraints via Field() for docs
•model_json_schema() was called .schema() in v1
•Deeply nested models generate large schemas that can slow down OpenAPI UI rendering

model_json_schema() generates JSON Schema from your model. Field constraints, descriptions, and examples all appear in the schema. FastAPI uses this to build Swagger UI automatically.

•Field constraints automatically become JSON Schema validation keywords

from pydantic import BaseModel, Field

class Item(BaseModel):
    name: str = Field(min_length=1, description="Item name")
    price: float = Field(gt=0)

schema = Item.model_json_schema()
print(schema['properties']['name'])

{'description': 'Item name', 'minLength': 1, 'title': 'Name', 'type': 'string'}

Custom validators are not reflected in the schema -- use Field() constraints for docs

Question 14 / 18

How do you handle datetime and UUID fields in Pydantic?

Pydantic natively supports Python's datetime, date, time, timedelta, and UUID types with automatic parsing and serialization.

datetime handling:

Accepts ISO 8601 strings ("2024-01-15T10:30:00Z"), Unix timestamps, and datetime objects
Serializes to ISO 8601 by default in JSON
Pydantic v2 validates timezone awareness based on the annotation

UUID handling:

Accepts UUID strings and UUID objects
Validates format automatically
Serializes to string in JSON

Common types:

datetime -- date and time
date -- date only
time -- time only
timedelta -- duration
UUID / UUID4 -- universally unique identifier

Pseudo Code

from datetime import datetime
from uuid import UUID

class Event(BaseModel):
    id: UUID
    starts_at: datetime
    # Pydantic parses ISO strings, timestamps, etc.

Code

from pydantic import BaseModel, field_validator, Field
from datetime import datetime, date, timedelta
from uuid import UUID, uuid4


class Event(BaseModel):
    id: UUID
    title: str
    starts_at: datetime
    ends_at: datetime
    event_date: date
    duration: timedelta


# Pydantic parses ISO 8601 strings automatically
event = Event(
    id="550e8400-e29b-41d4-a716-446655440000",
    title="Conference",
    starts_at="2024-06-15T09:00:00Z",
    ends_at="2024-06-15T17:00:00Z",
    event_date="2024-06-15",
    duration="PT8H"  # ISO 8601 duration: 8 hours
)

print(f"ID type: {type(event.id).__name__}")
print(f"ID: {event.id}")
print(f"Starts: {event.starts_at}")
print(f"Date: {event.event_date}")
print(f"Duration: {event.duration}")

# Serialization to JSON-compatible types
data = event.model_dump(mode='json')
print(f"\nJSON serialized:")
print(f"  id: {data['id']} (type: {type(data['id']).__name__})")
print(f"  starts_at: {data['starts_at']}")

# Generate UUIDs with defaults
class Record(BaseModel):
    id: UUID = Field(default_factory=uuid4)
    created_at: datetime = Field(default_factory=datetime.now)
    label: str

from pydantic import Field
rec = Record(label="test")
print(f"\nAuto-generated ID type: {type(rec.id).__name__}")
print(f"Auto-generated created_at type: {type(rec.created_at).__name__}")

ID type: UUID
ID: 550e8400-e29b-41d4-a716-446655440000
Starts: 2024-06-15 09:00:00+00:00
Date: 2024-06-15
Duration: 8:00:00

JSON serialized:
id: 550e8400-e29b-41d4-a716-446655440000 (type: str)
starts_at: 2024-06-15T09:00:00Z

Auto-generated ID type: UUID
Auto-generated created_at type: datetime

Key Points

•Pydantic parses ISO 8601 strings into datetime/date/time objects automatically
•UUID strings are validated and converted to UUID objects
•model_dump(mode='json') serializes datetime to ISO strings and UUID to string
•Use default_factory=uuid4 or default_factory=datetime.now for auto-generated values

Gotchas

•datetime without timezone info is treated as naive -- use AwareDatetime from pydantic for timezone-required fields
•model_dump() returns Python objects (UUID, datetime); model_dump(mode='json') returns strings
•timedelta parsing from strings uses ISO 8601 duration format (PT8H), not human-friendly format
•default_factory (not default) must be used for mutable defaults like uuid4()

Pydantic parses ISO 8601 strings into datetime objects and UUID strings into UUID objects. Use model_dump(mode='json') to serialize back to strings. default_factory=uuid4 auto-generates IDs.

•ISO 8601 strings auto-parsed to datetime; UUID strings to UUID objects

from pydantic import BaseModel
from datetime import datetime
from uuid import UUID

class Event(BaseModel):
    id: UUID
    created: datetime

e = Event(id="550e8400-e29b-41d4-a716-446655440000", created="2024-01-15T10:30:00Z")
print(type(e.id).__name__, type(e.created).__name__)

UUID datetime

Use default_factory (not default) for uuid4 and datetime.now

Question 15 / 18

What is model_validate() and how does it differ from model construction?

Pydantic v2 provides multiple ways to create model instances, each with different validation behavior.

Methods:

Method	Input	Validates?	Use case
`Model(**data)`	keyword args	Yes	Normal construction
`Model.model_validate(data)`	dict or object	Yes	Parse from dict/ORM
`Model.model_validate_json(json_str)`	JSON string	Yes	Parse from JSON
`Model.model_construct(**data)`	keyword args	No	Skip validation (perf)

model_validate():

Replaces v1's .parse_obj()
Accepts dicts, objects with attributes (if from_attributes=True), or model instances
Runs all validators

model_construct():

Creates an instance without any validation
Useful for trusted data from your own database where speed matters
Dangerous with untrusted data -- no type checks, no validators

Pseudo Code

# With validation (safe)
user = User.model_validate({"name": "alice", "age": 30})
user = User.model_validate_json('{"name": "alice", "age": 30}')

# Without validation (fast but unsafe)
user = User.model_construct(name="alice", age=30)

Code

from pydantic import BaseModel, field_validator, ValidationError


class User(BaseModel):
    username: str
    age: int

    @field_validator('username')
    @classmethod
    def lowercase_username(cls, v: str) -> str:
        return v.lower()

    @field_validator('age')
    @classmethod
    def check_age(cls, v: int) -> int:
        if v < 0:
            raise ValueError('age must be non-negative')
        return v


# 1. Normal construction -- validates
user1 = User(username="ALICE", age=30)
print(f"Constructor: {user1.username}, {user1.age}")

# 2. model_validate from dict -- validates
user2 = User.model_validate({"username": "BOB", "age": 25})
print(f"model_validate: {user2.username}, {user2.age}")

# 3. model_validate_json from JSON string -- validates
user3 = User.model_validate_json('{"username": "CHARLIE", "age": 35}')
print(f"model_validate_json: {user3.username}, {user3.age}")

# 4. model_construct -- NO validation (dangerous!)
user4 = User.model_construct(username="NOT_LOWERED", age=-999)
print(f"model_construct: {user4.username}, {user4.age}")
# Notice: username NOT lowered, negative age NOT caught!

# model_validate from ORM-like object
class DBUser:
    def __init__(self):
        self.username = "FROM_DB"
        self.age = 40

class UserORM(BaseModel):
    model_config = {"from_attributes": True}
    username: str
    age: int

    @field_validator('username')
    @classmethod
    def lower(cls, v: str) -> str:
        return v.lower()

user5 = UserORM.model_validate(DBUser())
print(f"from_attributes: {user5.username}, {user5.age}")

# Validation error example
try:
    User.model_validate({"username": "test", "age": -5})
except ValidationError as e:
    print(f"Validation failed: {e.errors()[0]['msg']}")

Constructor: alice, 30
model_validate: bob, 25
model_validate_json: charlie, 35
model_construct: NOT_LOWERED, -999
from_attributes: from_db, 40
Validation failed: Value error, age must be non-negative

Key Points

•model_validate() replaces parse_obj() -- validates a dict or object into a model
•model_validate_json() replaces parse_raw() -- parses and validates a JSON string
•model_construct() skips all validation for performance with trusted data
•from_attributes=True in model_config enables model_validate on ORM objects

Gotchas

•model_construct() skips ALL validation including type coercion -- use only with trusted data
•model_construct() also skips field_validators so computed/normalized values may be wrong
•model_validate_json() is faster than json.loads() + model_validate() because it uses Rust parsing
•Passing a model instance to model_validate does NOT re-validate by default in v2

model_validate(dict) creates and validates a model from a dict (replaces parse_obj). model_validate_json(str) parses JSON. model_construct(**data) skips validation entirely for trusted data.

•model_validate runs validators; model_construct skips them entirely

from pydantic import BaseModel

class User(BaseModel):
    name: str
    age: int

# With validation
u1 = User.model_validate({"name": "Alice", "age": 30})
# Without validation (fast, unsafe)
u2 = User.model_construct(name="Alice", age="not_validated")
print(u1.age, u2.age)

30 not_validated

model_construct skips ALL validation -- types, constraints, and custom validators

Question 16 / 18

How do you use Pydantic's computed fields (computed_field)?

computed_field is a Pydantic v2 feature that adds derived properties to model serialization. Unlike @property, computed fields appear in model_dump() output and in the JSON Schema.

How it works:

Decorate a @property with @computed_field
The property's return type annotation determines the schema type
Computed fields appear in model_dump(), model_dump_json(), and JSON Schema
They are read-only -- not settable or included in input validation

vs @property:

@property alone: accessible via model.prop but NOT in serialized output
@computed_field + @property: accessible AND appears in serialization

Pseudo Code

class Order(BaseModel):
    unit_price: float
    quantity: int

    @computed_field
    @property
    def total(self) -> float:
        return self.unit_price * self.quantity

# total appears in model_dump() and JSON Schema

Code

from pydantic import BaseModel, computed_field


class Rectangle(BaseModel):
    width: float
    height: float

    @computed_field
    @property
    def area(self) -> float:
        return self.width * self.height

    @computed_field
    @property
    def perimeter(self) -> float:
        return 2 * (self.width + self.height)

    @computed_field
    @property
    def is_square(self) -> bool:
        return self.width == self.height


rect = Rectangle(width=5.0, height=3.0)

# Computed fields accessible as properties
print(f"Area: {rect.area}")
print(f"Perimeter: {rect.perimeter}")
print(f"Is square: {rect.is_square}")

# Computed fields appear in serialization
print(f"\nmodel_dump: {rect.model_dump()}")

# Computed fields in JSON Schema
schema = Rectangle.model_json_schema()
print(f"\nSchema properties: {list(schema['properties'].keys())}")


# Practical example: user with full name
class User(BaseModel):
    first_name: str
    last_name: str
    hourly_rate: float
    hours_worked: float

    @computed_field
    @property
    def full_name(self) -> str:
        return f"{self.first_name} {self.last_name}"

    @computed_field
    @property
    def total_pay(self) -> float:
        return round(self.hourly_rate * self.hours_worked, 2)


user = User(first_name="Alice", last_name="Smith", hourly_rate=45.50, hours_worked=38.5)
print(f"\n{user.full_name}: ${user.total_pay}")
print(f"Dump: {user.model_dump()}")

Area: 15.0
Perimeter: 16.0
Is square: False

model_dump: {'width': 5.0, 'height': 3.0, 'area': 15.0, 'perimeter': 16.0, 'is_square': False}

Schema properties: ['width', 'height', 'area', 'perimeter', 'is_square']

Alice Smith: $1751.75
Dump: {'first_name': 'Alice', 'last_name': 'Smith', 'hourly_rate': 45.5, 'hours_worked': 38.5, 'full_name': 'Alice Smith', 'total_pay': 1751.75}

Key Points

•computed_field makes @property values appear in model_dump() and JSON Schema
•Must stack @computed_field on top of @property
•Return type annotation is required for JSON Schema generation
•Computed fields are read-only -- they are not part of input validation

Gotchas

•@computed_field must come BEFORE @property in decorator order (top to bottom)
•Computed fields are recalculated on every access -- cache expensive computations manually
•You cannot exclude computed fields with exclude_unset since they are always 'set'
•computed_field was added in Pydantic v2 -- no v1 equivalent

@computed_field + @property adds derived values to model_dump() and JSON Schema. Unlike plain @property, the computed value appears in serialized output. Read-only, not part of input validation.

•computed_field makes properties appear in model_dump() output

from pydantic import BaseModel, computed_field

class Order(BaseModel):
    price: float
    qty: int

    @computed_field
    @property
    def total(self) -> float:
        return self.price * self.qty

o = Order(price=9.99, qty=3)
print(o.model_dump())

{'price': 9.99, 'qty': 3, 'total': 29.97}

@computed_field must be stacked above @property

Question 17 / 18

How do you handle recursive/self-referencing models?

Pydantic supports self-referencing models where a model has a field whose type is the model itself. This is essential for tree structures, nested comments, org charts, and similar recursive data.

How it works in v2:

Simply reference the class name in the field type annotation
Pydantic v2 handles forward references automatically
Use Optional[Self] or list[Self] for the recursive field
The model_rebuild() method can resolve forward references if needed

Common patterns:

Tree nodes: children: list['TreeNode']
Linked lists: next_node: Optional['Node']
Nested comments: replies: list['Comment']
Category hierarchy: subcategories: list['Category']

Pseudo Code

class TreeNode(BaseModel):
    value: str
    children: list['TreeNode'] = []

# Pydantic resolves the forward reference automatically

Code

from pydantic import BaseModel
from typing import Optional


# Tree structure with self-referencing
class TreeNode(BaseModel):
    name: str
    value: int = 0
    children: list['TreeNode'] = []


# Build a tree from nested dicts
tree_data = {
    "name": "root",
    "value": 1,
    "children": [
        {
            "name": "child-a",
            "value": 2,
            "children": [
                {"name": "grandchild-a1", "value": 3}
            ]
        },
        {
            "name": "child-b",
            "value": 4,
            "children": []
        }
    ]
}

tree = TreeNode(**tree_data)
print(f"Root: {tree.name}")
print(f"Children: {[c.name for c in tree.children]}")
print(f"Grandchild: {tree.children[0].children[0].name}")


# Linked list pattern
class LinkedNode(BaseModel):
    value: str
    next_node: Optional['LinkedNode'] = None


linked = LinkedNode(
    value="first",
    next_node={"value": "second", "next_node": {"value": "third"}}
)

current = linked
values = []
while current:
    values.append(current.value)
    current = current.next_node
print(f"\nLinked list: {' -> '.join(values)}")


# Practical: nested comments
class Comment(BaseModel):
    author: str
    text: str
    replies: list['Comment'] = []


thread = Comment(
    author="Alice", text="Great post!",
    replies=[
        Comment(author="Bob", text="Thanks!", replies=[
            Comment(author="Alice", text="No problem!")
        ]),
        Comment(author="Charlie", text="I agree!")
    ]
)

def print_comment(c: Comment, depth: int = 0):
    print(f"{'  ' * depth}{c.author}: {c.text}")
    for r in c.replies:
        print_comment(r, depth + 1)

print("\nComment thread:")
print_comment(thread)

Root: root
Children: ['child-a', 'child-b']
Grandchild: grandchild-a1

Linked list: first -> second -> third

Comment thread:
Alice: Great post!
Bob: Thanks!
Alice: No problem!
Charlie: I agree!

Key Points

•Self-referencing works by using the class name as a string type or with from __future__ import annotations
•Pydantic v2 automatically resolves forward references for self-referencing models
•Use list['ModelName'] for tree structures and Optional['ModelName'] for linked structures
•Recursive validation applies at every level of nesting

Gotchas

•Deeply nested data can cause stack overflow or slow validation -- set practical depth limits
•model_rebuild() may be needed if the forward reference is defined in a complex module structure
•JSON Schema for recursive models uses $ref which some OpenAPI tools handle poorly
•Default mutable values like children: list['Node'] = [] are safe in Pydantic (unlike plain Python) because Pydantic copies defaults

Reference the model's own name as a string in type annotations for recursive structures. Pydantic v2 resolves forward references automatically. Use list['Model'] for trees and Optional['Model'] for linked lists.

•Use string type annotations for self-referencing fields

from pydantic import BaseModel

class TreeNode(BaseModel):
    name: str
    children: list['TreeNode'] = []

tree = TreeNode(name="root", children=[
    {"name": "child-a", "children": [{"name": "leaf"}]}
])
print(tree.children[0].children[0].name)

leaf

Deeply nested data can cause stack overflow -- set practical depth limits

Question 18 / 18

What is the difference between model_dump() and model_dump_json()?

model_dump() and model_dump_json() both serialize a model, but to different formats with different type handling.

model_dump():

Returns a Python dict with Python-native types
datetime stays as datetime, UUID stays as UUID, etc.
Use mode='json' parameter to get JSON-compatible Python types (strings for datetime/UUID)
Equivalent to v1's .dict()

model_dump_json():

Returns a JSON string directly
Uses Rust-based serializer (faster than json.dumps(model_dump()))
All types automatically converted to JSON-compatible formats
Equivalent to v1's .json()

When to use each:

model_dump() -- when you need a Python dict for further processing
model_dump(mode='json') -- when you need a JSON-compatible dict (e.g., for MongoDB)
model_dump_json() -- when you need a JSON string (e.g., for Redis, message queues)

Pseudo Code

# Python dict with native types
data_dict = model.model_dump()
# Python dict with JSON types
data_json_dict = model.model_dump(mode='json')
# JSON string
json_string = model.model_dump_json()

Code

from pydantic import BaseModel
from datetime import datetime
from uuid import UUID


class Event(BaseModel):
    id: UUID
    name: str
    starts_at: datetime
    tags: list[str]


event = Event(
    id="550e8400-e29b-41d4-a716-446655440000",
    name="Conference",
    starts_at="2024-06-15T09:00:00Z",
    tags=["tech", "python"]
)

# model_dump() -- Python dict with native types
python_dict = event.model_dump()
print("model_dump():")
print(f"  id type: {type(python_dict['id']).__name__}")
print(f"  starts_at type: {type(python_dict['starts_at']).__name__}")
print(f"  value: {python_dict}")

# model_dump(mode='json') -- Python dict with JSON-compatible types
json_dict = event.model_dump(mode='json')
print("\nmodel_dump(mode='json'):")
print(f"  id type: {type(json_dict['id']).__name__}")
print(f"  starts_at type: {type(json_dict['starts_at']).__name__}")
print(f"  value: {json_dict}")

# model_dump_json() -- JSON string
json_str = event.model_dump_json()
print(f"\nmodel_dump_json():")
print(f"  type: {type(json_str).__name__}")
print(f"  value: {json_str}")

# model_dump_json with indent
pretty = event.model_dump_json(indent=2)
print(f"\nPretty JSON:\n{pretty}")

# Both support the same filtering options
print(f"\nExclude tags: {event.model_dump(exclude={'tags'})}")
print(f"Include only name: {event.model_dump_json(include={'name'})}")

model_dump():
id type: UUID
starts_at type: datetime
value: {'id': UUID('550e8400-e29b-41d4-a716-446655440000'), 'name': 'Conference', 'starts_at': datetime.datetime(2024, 6, 15, 9, 0, tzinfo=TzInfo(UTC)), 'tags': ['tech', 'python']}

model_dump(mode='json'):
id type: str
starts_at type: str
value: {'id': '550e8400-e29b-41d4-a716-446655440000', 'name': 'Conference', 'starts_at': '2024-06-15T09:00:00Z', 'tags': ['tech', 'python']}

model_dump_json():
type: str
value: {"id":"550e8400-e29b-41d4-a716-446655440000","name":"Conference","starts_at":"2024-06-15T09:00:00Z","tags":["tech","python"]}

Pretty JSON:
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"name": "Conference",
"starts_at": "2024-06-15T09:00:00Z",
"tags": [
"tech",
"python"
]
}

Exclude tags: {'id': UUID('550e8400-e29b-41d4-a716-446655440000'), 'name': 'Conference', 'starts_at': datetime.datetime(2024, 6, 15, 9, 0, tzinfo=TzInfo(UTC))}
Include only name: {"name":"Conference"}

Key Points

•model_dump() returns Python dict with native types (UUID, datetime objects)
•model_dump(mode='json') returns Python dict with JSON-compatible types (strings)
•model_dump_json() returns a JSON string using a fast Rust serializer
•Both methods support the same filtering params: include, exclude, exclude_unset, etc.

Gotchas

•model_dump() keeps native Python types that are NOT json.dumps()-compatible without a custom encoder
•model_dump_json() is faster than json.dumps(model_dump(mode='json')) due to Rust serialization
•FastAPI internally uses model_dump(mode='json') for response serialization
•model_dump_json(indent=2) is useful for debugging but adds overhead in production

model_dump() returns a Python dict with native types (UUID, datetime). model_dump(mode='json') returns a dict with JSON-compatible strings. model_dump_json() returns a JSON string directly using Rust for speed.

•model_dump keeps native types; model_dump_json serializes to JSON string

from pydantic import BaseModel
from uuid import UUID

class Item(BaseModel):
    id: UUID
    name: str

item = Item(id="550e8400-e29b-41d4-a716-446655440000", name="Widget")
print(type(item.model_dump()['id']).__name__)       # UUID
print(type(item.model_dump(mode='json')['id']).__name__)  # str
print(type(item.model_dump_json()).__name__)         # str

UUID
str
str

model_dump() output is NOT json.dumps()-safe without mode='json'

Built by onllm.dev

Home GitHub Support awesomePrep