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

Pydantic ломают не типы, а привычка валидировать «на глаз» Если модель используется как контракт, держите в ней только входные данные и правила проверки. Не тащите туда бизнес-логику, запросы к БД и вычисления, которые зависят от окружения — иначе объект становится неудобным и плохо тестируется. Есть наблюдение которое стоит проверить: большинство багов рождается не в самих полях, а на границе между сырым словарём и моделью. Там полезно явно фиксировать: — обязательные поля и значения по умолчанию; — алиасы для внешнего API; — строгие типы там, где нельзя «догадываться»; — отдельные модели для входа и ответа. Ещё одна типовая ошибка — полагаться на «автоматическое приведение». Строка в число, пустая строка в None, лишний ключ в payload — всё это удобно до первого инцидента. Если формат важен, лучше сделать ошибку явной, чем потом искать, почему данные тихо исказились 🔧 Для сложных payload’ов помогает правило: одна модель — одна задача. Вложенные структуры разбивайте на маленькие схемы, а преобразования выносите в отдельные функции. Тогда сериализация, валидация и тесты перестают мешать друг другу. Итог простой: Pydantic особенно силён там, где нужно жёстко описать границу системы. Чем раньше выловили мусорный вход, тем меньше кода придётся чинить дальше по цепочке.