Глава 2. Python – плюсы/минусы

Python часто выбирают не из‑за «идеальной архитектуры» «самой высокой производ», а из‑за очень практичной вещи: на нём быстрее всего превращать идею в работающий код. Это язык, на котором одинаково комфортно написать API, скрипт мигра данных, интеграцию со сторонним сервисом, джобу для очереди и небольшой ML‑пайплайн.

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

В этой главе разберём Python «по‑земному»: где он особенно хорош, где может подставить и как понять, подходит ли он под ваш сервис.

2.1. Что мы подразумеваем под Python‑бэкендом

Под «Python‑бэкендом» в этой книге обычно подразумевается:

– Python 3.x (желательно актуальный, не «как на сервере поставили 5 лет назад»).

– Web API на одном из фреймворков:

– FastAPI (часто лучший баланс для современных API),

– Django (если нужен «комбайн» с ORM, админкой и большим количеством встроенных решений),

– Flask (минималистичный вариант).

– Работа в контейнерах (часто Docker), чтобы окружение было повторяемым.

– Тесты и линтинг как обязательная часть проекта.

Что стоит установить для работы

Минимальный набор, который обычно облегчает жизнь:

– Python 3 (лучше ставить через менеджер версий вроде `pyenv`, если вы на macOS/Linux).

– pip (идёт вместе с Python) + менеджер зависимостей:

– `poetry` или `uv` (быстро и удобно),

– либо классический `pip` + `requirements.txt` (простая модель, но требует дисциплины).

– Docker (PostgreSQL/Redis/очереди удобно поднимать контейнерами).

– Postman/Insomnia или просто `curl` для ручной проверки API.

– Инструменты качества кода:

– форматирование: `ruff format` или `black`,

– линтинг: `ruff`,

– типизация: `mypy` или `pyright`,

– тесты: `pytest`.

Эти инструменты не «украшают» проект – они компенсируют те места, где Python по умолчанию менее строгий.

2.2. Плюсы Python

Плюс 1. Самая высокая скорость написания бизнес‑логики

Python ценят за то, что он позволяет писать много полезного кода с минимумом шума. Это особенно заметно в бизнес‑логике, где часто нужно:

– обработать входные данные;

– сходить в БД/кэш/внешний сервис;

– принять решение по правилам;

– вернуть результат.

В Python вы редко тратите время на «обвязку». Код получается коротким, читаемым и легко изменяемым.

Почему так выходит на практике:

– синтаксис простой и близкий к «псевдокоду»;

– много встроенных возможностей для работы со строками, коллекциями, датами;

– богатая стандартная библиотека;

– огромный выбор готовых библиотек под почти любую задачу.

Для продуктовой разработки это важно. Когда требования меняются каждую неделю, скорость внесения правок иногда важнее, чем идеальная модель типов или максимальная производительность.

Что вы почувствуете в проекте:

– быстро появляется «вертикальный срез» фичи (от API до результата);

– проще экспериментировать: менять правила, добавлять поля, перестраивать процесс;

– легче писать небольшие утилиты вокруг сервиса (например, скрипт импорта или диагностики).

Плюс 2. Отличен для интеграций, автоматизаций, data/ML

Python – фактически стандарт для задач, где нужно работать с данными и автоматизировать процессы:

– обработка файлов (CSV/Excel/JSON);

– интеграции с API внешних систем;

– фоновые задачи (выгрузки, перерасчёты, рассылки);

– пайплайны данных;

– аналитика и машинное обучение.

Важно, что это всё часто встречается не только в «data‑командах». Обычный продуктовый бэкенд регулярно сталкивается с задачами типа:

– загрузить прайс от партнёра;

– сопоставить сущности (матчинг);

– рассчитать метрики и сохранить агрегаты;

– прогнать правила качества данных;

– подготовить датасет для модели;

– интегрироваться с CRM, платёжкой, складом.

В Python‑мире для этого почти всегда есть зрелые библиотеки. Часто они появляются раньше и развиваются быстрее, чем аналоги в других экосистемах.

Практический эффект:

– меньше «велосипедов»;

– проще собирать конвейеры из готовых частей;

– удобнее поддерживать единую кодовую базу, где рядом живут API и data‑задачи.

Плюс 3. FastAPI даёт прекрасный DX и OpenAPI из коробки

FastAPI стал популярным по очень понятным причинам:

– он быстрый в разработке;

– поощряет типизацию (через type hints);

– автоматически генерирует OpenAPI‑схему;

– даёт интерактивную документацию (обычно Swagger UI) почти бесплатно.

DX (developer experience) здесь реально чувствуется:

– вы описали модель входа/выхода – и документация уже обновилась;

– клиентским командам проще тестировать API;

– меньше времени уходит на «а как этим пользоваться».

Кроме того, FastAPI подталкивает к более аккуратной структуре:

– явные модели запросов/ответов;

– валидация данных через схемы;

– понятная работа с зависимостями (dependency injection).

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

Плюс 4. Низкий порог входа и широкая доступность разработчиков

Python часто выбирают ещё и потому, что:

– его знают многие;

– на нём проще онбордить людей;

– он хорош для команд, где есть не только классические бэкендеры, но и аналитики/инженеры данных/автоматизаторы.

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

2.3. Минусы Python

Минус 1. Типизация слабее (mypy/pyright помогают, но не как Java/TS)

Python поддерживает type hints, и это большой шаг вперёд по сравнению с прошлым. Но важно честно признать: по строгости и «железобетонности» это обычно уступает языкам, где типизация – часть ядра (Java, Kotlin, TypeScript в строгом режиме).

В чём проблема на практике:

1) Типы не обязательны.

Вы можете не писать их вовсе – и код продолжит работать. Это означает, что типовая дисциплина держится на договорённостях и проверках в CI.

2) Типы не влияют на рантайм автоматически.

Даже если вы всё типизировали, на проде Python всё равно выполнит код, даже если вы передали «не то». Типы ловят ошибки на стадии анализа, но не защищают в рантайме сами по себе.

3) Сложные случаи типизации могут быть неудобными.

Дженерики, сложные объединения типов, протоколы, ковариантность – всё это есть, но часто воспринимается как «отдельная наука», и команда начинает избегать типизации в сложных местах.

mypy и pyright реально помогают:

– ловят ошибки в рефакторингах;

– улучшают автокомплит;

– повышают уверенность при изменениях.

Но это работает, только если:

– вы включили проверки и не отключаете их «ради скорости»;

– вы используете типы последовательно;

– вы аккуратно работаете с границами (входные данные из внешнего мира).

Практический вывод: типизация в Python – это инструмент качества, который нужно сознательно включать и поддерживать, иначе он «растворяется» в проекте.

Минус 2. Производительность часто ниже; async требует дисциплины

Python обычно медленнее по CPU‑задачам, чем Go/Java/Node (V8 часто быстрее в чистых вычислениях). В прикладном API это не всегда критично, потому что большинство запросов – это I/O:

– база данных;

– кэш;

– внешний сервис.

Но проблемы начинаются, когда:

– в запросе много преобразований данных;

– вы сериализуете/десериализуете большие объёмы JSON;

– вы делаете тяжёлые вычисления в обработчике запроса;

– вы случайно блокируете event loop (в async‑варианте).

Почему «async требует дисциплины»

FastAPI и современный Python‑стек часто используют `async`/`await`. Это мощно, но легко ошибиться:

– вы используете синхронную библиотеку внутри `async`‑эндпоинта;

– вы делаете блокирующий вызов (например, обычный HTTP‑клиент без async);

– вы запускаете CPU‑тяжёлое в том же потоке;

– вы не контролируете время ожидания и ретраи.

Снаружи это проявляется как странные симптомы:

– сервис «живой», но отвечает медленно;

– под нагрузкой резко растут задержки;

– метрики показывают, что CPU не загружен на 100%, но запросы висят.

Проблема не в том, что async «плохой». Проблема в том, что в Python легко смешать async и sync так, что вы сами себе создаёте пробки.

Обычно помогают практики:

– чётко выбирать: этот сервис в основном async или в основном sync;

– использовать подходящие библиотеки (async‑драйверы БД, async‑HTTP клиент);

– выносить CPU‑тяжёлое в фоновые воркеры;

– ограничивать параллелизм и ставить таймауты.

Минус 3. Параллелизм сложнее (GIL), обычно уходят в процессы/очереди

В Python есть известная особенность: GIL (Global Interpreter Lock) в CPython. Упрощённо: в одном процессе Python‑код не исполняется параллельно на нескольких ядрах так, как вы могли бы ожидать от потоков.

Что это значит для бэкенда:

– Для I/O‑нагрузки это часто не критично: пока вы ждёте сеть/БД, можно обрабатывать другие запросы.

– Для CPU‑нагрузки это становится проблемой: если у вас тяжёлая обработка данных, один процесс будет упираться в одно ядро.

Типичные решения в продакшене:

1) Масштабирование процессами

Запускают несколько воркеров веб‑сервера (несколько процессов). Это даёт использование нескольких ядер.

2) Очереди и фоновые задачи

CPU‑тяжёлое выносят из HTTP‑обработчика в отдельные воркеры: так API остаётся быстрым, а тяжёлая работа выполняется асинхронно.

3) Отдельные сервисы для тяжёлых расчётов

Иногда проще вынести вычисления в отдельный компонент (на другом языке или в отдельной инфраструктуре), чем бороться с ограничениями внутри одного API.

4) Нативные расширения

Для некоторых задач используют библиотеки, которые внутри реализованы на C/C++/Rust и обходят ограничения, потому что тяжёлая часть выполняется вне интерпретатора.

Практическая мысль: Python отлично работает как «клей» и как слой бизнес‑логики, но если ваш сервис – это постоянные тяжёлые вычисления на запрос, вам почти наверняка понадобится отдельная стратегия параллелизма.

Минус 4. Управление зависимостями и окружением может быть источником боли

Это не уникально для Python, но в Python это встречается чаще из‑за большого количества способов «как правильно» управлять пакетами.

В реальных проектах проблемы выглядят так:

– «у меня локально работает, в CI нет»;

– «после обновления зависимости всё сломалось»;

– «на сервере другая версия Python»;

– «библиотека тянет несовместимые версии зависимостей».

Эта боль сильно уменьшается, если:

– фиксировать версии зависимостей;

– использовать виртуальные окружения;

– контейнеризировать приложение;

– иметь понятный способ сборки (один, а не три разных в разных командах).