Dataclasses and Pydantic: Validate Data at the Boundary

class Product(BaseModel):
    model_config = ConfigDict(frozen=True)

    sku: str = Field(pattern=r"^LUM-[A-Z]{2}-\d{3}
quot;)
    name: str
    category: Category
    price_eur: float = Field(ge=0, description="Illustrative price, not a real quote")
    specs: dict[str, SpecValue] = Field(default_factory=dict)
    protocols: list[str] = Field(default_factory=list)
    ip_rating: str | None = Field(default=None, pattern=r"^IP\d{2}
quot;)
    in_stock: bool = True
    tenant_visibility: Visibility = "public"

Read it field by field:

• sku must match a pattern, and price_eur must be at least 0.
• category must be one of five literal strings.
• ip_rating is optional but must be "IP" plus two digits if present.
• specs and protocols default to fresh empty containers (default_factory, a callable that generates the default).
• frozen=True makes instances read only, but the docs' own example shows a frozen model does not stop a dictionary field being changed in place, so specs can still be modified.

Requirements is the opposite shape: every field is optional, because a request rarely names everything.

Verified: capstone/fde-product-discovery-copilot/app/models.py

class Requirements(BaseModel):
    """What the customer asked for, as structured data. Every field is optional."""

    category: Category | None = None
    quantity: int | None = Field(default=None, gt=0)
    budget_eur: float | None = Field(default=None, gt=0)
    protocols: list[str] = Field(default_factory=list)
    environment: list[str] = Field(default_factory=list)
    must_have: list[str] = Field(default_factory=list)
    nice_to_have: list[str] = Field(default_factory=list)
    keywords: list[str] = Field(default_factory=list)  # topic words, for example "vibration"
    skus: list[str] = Field(default_factory=list)  # products named in the request (resolved in code)

Here quantity and budget_eur use gt=0, so a request for zero pumps is rejected, while leaving them out is fine.

Worked example

Assumptions: the three rows are illustrative; the output below is from an actual run of the lesson's parse_catalog.

Rows: a valid product; one with SKU vs-100 and a price of -5; one with category toasters.

[RowError(row=1, fields=('sku', 'price_eur')), RowError(row=2, fields=('category',))]

Row 0 passes. Row 1 fails on two fields at once, and row 2 on one. The full catalog, data/products.json, validates with 40 products and 0 errors, 5 of them partner-only.

Printing the exception itself is different: Pydantic's default message includes the submitted value. A run on a bad SKU and a text price printed these lines, documentation links left out:

2 validation errors for Product
sku
  String should match pattern '^LUM-[A-Z]{2}-\d{3}
#x27; [type=string_pattern_mismatch, input_value='vs-100', input_type=str]
price_eur
  Input should be a valid number, unable to parse string as a number [type=float_parsing, input_value='free', input_type=str]

If the field were a customer's free text, it would land in your logs. The capstone's error handler therefore sends back field names only, and so does bad_fields.

In the interview: "Why use Pydantic instead of plain type hints or dataclasses?" A good answer: "Hints and dataclasses describe data but do not check it. Pydantic validates at construction, so I check untrusted input once at the boundary and the rest of the code can rely on the types. I would still use a dataclass for internal values I create myself."

Build it

The loader validates each row once and collects problems instead of stopping at the first.

Verified: capstone/fde-product-discovery-copilot/lessons/M1-L2/m1_l2_boundary.py

def bad_fields(exc: ValidationError) -> tuple[str, ...]:
    """Where the problems are, never what was submitted (the value may be private)."""
    return tuple(".".join(str(part) for part in e["loc"]) or "(whole body)" for e in exc.errors())


def parse_catalog(rows: list[dict[str, object]]) -> tuple[list[Product], list[RowError]]:
    """Validate every row once, at the edge. Good rows become Products, bad rows become RowErrors."""
    products: list[Product] = []
    errors: list[RowError] = []
    for index, row in enumerate(rows):
        try:
            products.append(Product.model_validate(row))
        except ValidationError as exc:
            errors.append(RowError(index, bad_fields(exc)))
    return products, errors

This lesson test shows lax and strict mode differ.

Verified: capstone/fde-product-discovery-copilot/lessons/M1-L2/test_m1_l2_boundary.py

def test_lax_mode_converts_and_strict_mode_does_not():
    assert Product.model_validate({**GOOD, "price_eur": "349"}).price_eur == 349.0
    with pytest.raises(ValidationError):
        Product.model_validate({**GOOD, "price_eur": "349"}, strict=True)

Run ./.venv/Scripts/python -m pytest lessons/M1-L2 -q from the capstone folder.

Predict first. What does parse_catalog return for the three rows "just text", None and {}? Compare with the last test in the file.

Exercise

Write parse_requirements_json(raw: str): it takes JSON text and returns a Requirements object or the tuple of wrong field paths.

Acceptance criteria:

• Valid JSON with quantity: 40 returns a Requirements whose quantity is 40.
• quantity: 0 and an unknown category both appear in the returned paths.
• Text that is not JSON returns one entry that says the whole body was wrong.
• No submitted value appears in the result.

Done when your function passes those four cases. A reference solution is in lessons/M1-L2/m1_l2_solution_requirements.py; write yours first.

Common mistakes

• Assuming a dataclass validates. It does not. Use Pydantic for outside input.
• Validating twice. Re-checking deep in the code hides the real boundary.
• Logging the exception text. It carries submitted values. Log paths and error types.
• Missing lax conversion. "349" becomes 349.0. Use strict mode if partners must send numbers.
• A shared mutable default. Use default_factory for lists and dictionaries.
• Encoding policy as a type. ge=0 is a rule someone owns. Confirm it.

Knowledge check

You can now

• Say which of a record, dataclass and Pydantic model checks its input.
• Write field rules for a range, a pattern and a closed set.
• Validate rows once and report failures by row and field.
• Explain lax versus strict mode.
• Keep submitted values out of logs.

Further reading

• Pydantic: Models, on validation, strict mode and frozen models.
• Pydantic: Fields, for constraints and default_factory.
• Python: dataclasses, for what the decorator generates.

Last verified: 2026-11-02

Next

FastAPI: an AI-ready service