<b>Pydantic ломают не типы, а привычка валидировать «на глаз»</b>

<b>Pydantic ломают не типы, а привычка валидировать «на глаз»</b>

Если модель в Pydantic ведёт себя странно, обычно проблема не в библиотеке, а в схеме. Частые ошибки:
— поле объявили как str, а в payload прилетает int и где-то дальше это молча приводится;
— вложенные модели не описали явно, поэтому структура расползается по dict;
— optional-поля смешали с дефолтами и потом ловят неожиданные None.

Для API это особенно больно: один кривой вход превращается в баг, который сложно поймать в коде. Pydantic хорош тем, что делает контракт явным: входной payload либо проходит, либо падает сразу. Это экономит время и в Django-проектах, и в FastAPI-сервисах, и в скриптах, где данные приходят из CSV, очереди или внешнего API.

Есть три правила, которые почти всегда окупаются:
• описывать вложенность через отдельные модели;
• не прятать обязательность полей за слишком мягкими типами;
• отдельно валидировать бизнес-условия, а не пытаться запихнуть всё в одну строку аннотации.

Если нужно преобразование, делайте его явно: до модели или через валидаторы. Иначе схема начнёт «прощать» лишнее, а потом это вылезет в проде в самом неудобном месте.

<b>Лучший Pydantic-код — это не самый умный, а самый предсказуемый.</b>