Посты за июнь 2026

Pydantic ломается не в моделях, а в границах данных: 5 правил, которые спасают API Если Pydantic у вас «иногда валится без причины», проблема обычно не в валидации, а в том, что входной контракт размыт. Модель должна быть не копией JSON, а фильтром: принимать лишнее только осознанно, а поля с бизнес-смыслом делать явными. • Делайте отдельные схемы для input и output. Одна модель на всё почти всегда приводит к лишним optional-полям и странным дефолтам. • Не прячьте бизнес-логику в валидаторах. Валидатор проверяет форму и типы, а не решает, можно ли создавать объект. • Явно задавайте alias, если внешний API живёт на snake_case, а внутренний код — на другом соглашении. • Для вложенных объектов лучше провалиться сразу, чем тащить None глубоко в сервисный слой. Ещё одна частая ошибка — надеяться, что Pydantic «сам всё приведёт к нужному виду». Он приведёт, но иногда слишком щедро: строка станет числом, пустой список — валидным значением, а лишнее поле тихо пройдёт дальше. Для критичных границ лучше включать строгую валидацию и не полагаться на магию преобразований. Если модель начинает разрастаться, это сигнал разнести её на DTO, response-схемы и внутренние типы. Так код проще тестировать, а ошибка становится локальной: не в десяти сервисах, а в одном месте входа.

Starlette — это не «мини-FastAPI», а каркас, который удобно ломать и собирать под себя Если нужен тонкий HTTP-слой для микросервиса, вебхуков или внутреннего API, Starlette часто выигрывает за счёт простоты: маршруты, middleware, фоновые задачи, WebSocket — без лишней магии. Он хорош там, где важнее контролировать поведение, чем тащить большой фреймворк ради пары эндпоинтов. Что обычно делают неправильно: • Пишут sync-хендлеры и потом удивляются блокировкам в проде • Вешают тяжёлую логику прямо в endpoint вместо сервиса или очереди • Игнорируют lifespan-события и теряют инициализацию клиентов, пулов, кешей • Смешивают ручную работу с request/response и начинают плодить дублирование Если проект растёт, Starlette удобно использовать как базу для тонкой архитектуры: отдельно слой транспорта, отдельно бизнес-логика, отдельно интеграции. Это особенно заметно в async-проектах, где один плохо написанный handler может тормозить весь ворклоад. Ещё плюс: Starlette легко тестировать и легче читать в ревью, когда в коде нет лишнего «магического» слоя. Но это работает только если сразу договориться о границах: где валидируются данные, где ловятся ошибки, где живут зависимости. Хорошее правило простое: если вам нужен контроль над HTTP и минимум абстракций, Starlette — не компромисс, а осознанный выбор.

Scrapy ломается не на парсинге, а на плохой архитектуре проекта Если у вас пауки начинают дублировать запросы, падать на редких страницах и засорять пайплайны, проблема обычно не в XPath. В Scrapy лучше сразу разнести роли: spider только собирает URL и поля, item pipeline чистит и валидирует, middleware отвечает за сеть и антибот-логику. Три вещи, которые экономят часы: — не хранить бизнес-логику в parse(), иначе паук быстро превращается в свалку; — делать idempotent-обработку items, чтобы повторный прогон не плодил дубликаты; — выносить настройки селекторов, заголовков и retry-политик в отдельные модули, а не копировать по спайдерам. Если нужно ускорение, смотрите не только на concurrency, но и на лимиты внешнего сайта: иногда узкое место — DNS, иногда блокировки, иногда тяжелый pipeline. Еще полезно логировать причины пропуска item, а не только ошибки, тогда видно, где теряются данные. Хороший Scrapy-проект — это когда паук можно остановить, запустить заново и получить тот же набор данных без ручной чистки.

7 ошибок в Python-скриптах, из-за которых ломается даже простой автоматизатор Ошибка 1 — смешивать логику, ввод-вывод и парсинг в одном файле. Когда скрипт растёт, его уже нельзя нормально тестировать и переиспользовать. Ошибка 2 — ловить except: без конкретики. Так прячутся реальные баги: сетевые сбои, битые данные, неверный формат ответа. Лучше ловить только ожидаемые исключения и логировать контекст. Ошибка 3 — игнорировать таймауты и ретраи. Любой запрос к API, БД или внешнему сервису должен либо быстро падать, либо повторяться по правилам. Иначе зависание выглядит как «всё работает», пока очередь не встанет. Ошибка 4 — тащить в прод сырые print() и магические константы. Для отладки годится, для эксплуатации нужен logging, конфиг и явные параметры. Тогда скрипт можно запускать и вручную, и по cron, и из Django-задачи. Держите код маленькими блоками: отдельная функция для данных, отдельная для действий, отдельная для ошибок. Такой Python проще чинить, проще покрывать тестами и легче передавать другому разработчику.

Python-код ломается не из-за языка, а из-за мелких привычек в проекте Есть наблюдение которое стоит проверить: в Python чаще всего страдает не алгоритм, а дисциплина вокруг него. Один и тот же код через месяц выглядит как набор случайных решений, если не держать базовые правила. — Не мешайте бизнес-логику, I/O и форматирование в одной функции. Как только там появляется третья ответственность, тестировать уже неудобно. — Явно отделяйте границы: входные данные валидируйте сразу, наружу отдавайте понятные структуры, а не сырые dict без схемы. — Не ловите Exception “на всякий случай”. Лучше поймать конкретную ошибку и понять, где именно сломался сценарий. — Если есть повторяющийся кусок, вынесите его раньше, чем он расползётся по трем модулям. Рефакторинг позже почти всегда дороже. Отдельно смотрите на имена: плохое имя в Python живёт дольше, чем плохая функция. Когда переменная называется data, result или temp, через две недели её смысл уже приходится вспоминать. Если нужен код, который переживёт чужую правку, держите три вещи: короткие функции, явные типы/схемы, понятные имена. Это скучно, зато именно так Python остаётся удобным, а не превращается в архив сюрпризов.