Расскажите о случае, когда вы осознанно выбрали или отвергли Pydantic для проекта.

Реальный кейс: отказ от Pydantic в пользу TypedDict

# Было: медленная валидация 50k сообщений/сек через Pydantic
from pydantic import BaseModel

class TradeEvent(BaseModel):
    symbol: str
    price: float
    volume: int

def process_kafka_message(raw: dict) -> TradeEvent:
    return TradeEvent(**raw)  # Валидация на каждое сообщение

# Стало: TypedDict + разовая валидация на входе Kafka-консьюмера
from typing import TypedDict

class TradeEvent(TypedDict):
    symbol: str
    price: float
    volume: int

def process_kafka_message(raw: dict) -> TradeEvent:
    return raw  # type: ignore  # Доверяем Kafka-схеме (Avro/Protobuf)

Результат: throughput вырос с 50k до 200k сообщений/сек при той же инфраструктуре. Валидация была перенесена на уровень Schema Registry (Avro).

Выбор Pydantic: когда брать, когда отказаться

Pydantic — мощный инструмент, но не серебряная пуля. Осознанный выбор зависит от характера проекта, нагрузки и уже используемого стека.

Когда стоит взять Pydantic

• FastAPI-проекты — Pydantic интегрирован нативно, даёт автодокументацию через JSON Schema и валидацию request/response без дополнительного кода.
• Парсинг внешних данных — API-ответы, CSV/JSON-файлы, Kafka-сообщения. Явная схема защищает от «мусора» на входе.
• Конфигурация через BaseSettings — чтение из env-переменных с типизацией и дефолтами прямо из коробки.
• CLI-инструменты и data-pipelines — контракт между стадиями пайплайна фиксируется через модели.

Когда стоит отказаться от Pydantic

• Производительность в tight loop — если модель создаётся миллионы раз в секунду (например, парсинг строк биржевых котировок), даже Pydantic v2 создаёт заметный overhead. Лучше dataclasses или TypedDict.
• Только dataclass-семантика — если нужна просто структура без валидации, @dataclass или NamedTuple достаточно.
• ORM-объекты напрямую — использование Pydantic-моделей вместо SQLAlchemy ORM-объектов внутри слоя репозитория создаёт двойную конвертацию.
• Проекты без типизации — если команда не использует TypeScript-стиль в Python, Pydantic будет восприниматься как overhead.

Реальный кейс: выбор Pydantic для multi-tenant API

В API с 15+ клиентами, каждый из которых присылал JSON в слегка разном формате, Pydantic с model_validator(mode='before') позволил нормализовать входные данные на уровне схемы без if-цепочек в бизнес-логике. Это упростило тестирование и сделало контракт самодокументируемым через model_json_schema().

Подводные камни

• Pydantic v1 vs v2 — если библиотека-зависимость использует v1 (sqlmodel, старые версии FastAPI), возникают конфликты при одновременном использовании.
• Избыточная валидация внутри сервисного слоя при уже валидированных FastAPI-запросах — двойные накладные расходы без пользы.
• Использование model_dump(exclude_unset=True) для PATCH-эндпоинтов — частый паттерн, который легко забыть.
• Не все случаи требуют Pydantic — иногда достаточно dataclasses с __post_init__ для простой инициализационной логики.

• Выдумывать опыт или говорить слишком общими фразами
• Не объяснять свою личную роль в работе с Pydantic
• Не показывать результат, метрики или извлечённые уроки

• Может подготовить честный пример использования Pydantic
• Показывает свою роль, решения и результат
• Умеет рефлексировать над trade-offs и уроками