Прямой ответ
Python-стек 2026 года сходится к устойчивому дефолтному набору, отклонения от которого должны быть обоснованы задачей, а не вкусом: язык — 3.11+ (скорость, современная типизация), веб — FastAPI для API / Django для «полных» приложений с админкой, БД — PostgreSQL + SQLAlchemy 2.0 + Alembic, валидация/модели — pydantic, тесты — pytest, линт/формат — ruff, типы — mypy, упаковка/среды — pyproject.toml + uv, CI — GitHub Actions, фоновые задачи — Celery (или проще — по нагрузке). Эта страница — карта решений по каждому слою: критерий выбора, дефолт и ссылка на детальный разбор; коллекция из ста статей линии собирается в связную систему именно здесь.
Слой 1. Язык и окружения
Python 3.11+ — не обсуждается (3.9/3.10 — легаси с догоняющими библиотеками; миграция версии — отдельный воркфлоу). Менеджер сред и зависимостей: uv (Rust, в разы быстрее pip, lock-файлы, замена pyenv+pip-tools+virtualenv одним инструментом) — новый дефолт; venv+pip — базовый уровень, conda — для научного стека с тяжёлыми бинарными зависимостями (сравнение — в разборе окружений). Типизация — с первого дня нового проекта (gradual-внедрение в легаси — гайд по mypy).
Слой 2. Веб и API
API/микросервис — FastAPI (валидация+OpenAPI из объявлений, DI; механика зависимостей); критерии против Flask — в сравнении. Приложение с админкой/ORM/CMS-задачами — Django (всё включено; локальная разработка — гайд). Дизайн самого API — независимо от фреймворка (REST-практика), контракт — OpenAPI (контрактная разработка); внутренние сервис-сервисные вызовы при росте — gRPC (основы), границы архитектуры — микросервисные паттерны. Аутентификация — сессии или OAuth+JWT по сценарию (разбор); realtime — WebSocket с честной оценкой «а не SSE ли» (практика).
Слой 3. Данные
Основная БД — PostgreSQL почти всегда (локально — docker-сервис из гайда); SQLite — когда встроенности достаточно (критерии). ORM — SQLAlchemy 2.0 (сессии и N+1 — практика, борьба с лишними запросами) + Alembic-миграции (воркфлоу). Аналитика — pandas (очистка — паттерны, скорость — векторизация, агрегации — groupby, джойны — антипаттерны) поверх NumPy (основы); большие файлы — parquet (форматы) + DuckDB (SQL по файлам); ML без GPU — sklearn (практика). Кеш — по лестнице lru_cache→Redis (паттерны).
Слой 4. Качество и поставка
Тесты — pytest (фикстуры и параметризация), моки — только на границах (паттерны), интеграционные — Testcontainers (гайд); нагрузка — Locust (методика). Статика — ruff+mypy в pre-commit (хуки, ruff) и CI (Actions-матрица); безопасность — bandit+пик-чеклист (инъекции); зависимости — lock+Dependabot (процесс). Упаковка — pyproject+uv, публикация через trusted publishing (гайд); документация — MkDocs/Sphinx (выбор); секреты — env/хранилища (правила); логи — структурные (практика), метрики — Prometheus/Grafana (мониторинг).
Как читать эту карту: принципы поверх инструментов
Три правила, которые переживут любую смену моды. Скучные технологии побеждают: дефолтный стек выше — это миллионы проектов и ответы на любой вопрос; экзотика оправдана измеренной болью, а не интересом. Границы важнее внутренностей: качество проекта определяется дисциплиной на границах (валидация ввода, контракты API, миграции, секреты), а не маркой фреймворка внутри. Инструмент следует за задачей: «какой фреймворк лучший» — неправильный вопрос; правильный — «что за задача, какие ограничения (команда, нагрузка, приватность), какой минимум сложности их закрывает». Сто статей этой линии — детали к этим трём принципам: от выбора ноутбука под стек до фоновых задач.
Три готовых набора под типовые задачи
Чтобы карта не оставалась абстракцией — три собранных конфигурации. Веб-сервис/API: Python 3.12 + FastAPI + pydantic + PostgreSQL/SQLAlchemy/Alembic + Redis-кеш + pytest/Testcontainers + ruff/mypy + uvicorn за reverse-proxy + Prometheus-метрики; фоновые задачи — Celery с Redis-брокером, когда появятся. Аналитика и данные: Python 3.12 + Jupyter + pandas/NumPy + DuckDB для тяжёлых запросов по файлам + parquet как формат хранения + matplotlib для диагностики + sklearn, если нужен ML на таблицах; качество кода — те же ruff и pytest, потому что аналитический скрипт живёт дольше, чем кажется. Инструмент/автоматизация: Python 3.12 + typer для CLI + httpx для внешних вызовов + rich для вывода + pyproject со [project.scripts] для установки через pipx; при необходимости GUI — PySide6 или локальный веб-интерфейс. Наборы пересекаются в главном — язык, упаковка, линтер, тесты, секреты в env — и это не случайность: базовый слой гигиены одинаков для любой задачи, различается только «профильная» середина. Если проект растёт из одной категории в другую (скрипт превращается в сервис), миграция затрагивает середину стека, а база остаётся — поэтому начинать даже маленький скрипт с pyproject и тестов дешевле, чем «потом переделать».
Практический сценарий: старт проекта за один день
Как карта применяется на практике — день из жизни нового внутреннего сервиса. Утро: uv init создаёт проект с pyproject.toml; requires-python = ">=3.12"; зависимости — fastapi, sqlalchemy, pydantic-settings; dev-группа — pytest, ruff, mypy. Структура — src-layout, первые модули: конфиг (pydantic-settings из env), домен (dataclasses с поведением), API (FastAPI-роутеры с pydantic-DTO на границе). Обед: docker-compose поднимает PostgreSQL; Alembic-инициализация и первая миграция; эндпоинт healthcheck и первый ресурс — с валидацией, сессией через Depends и тестами на TestClient сразу (не «потом допишем»). Вечер: ruff+mypy в pre-commit, GitHub Actions с матрицей 3.12/3.13, деплой-скрипт (образ в реестр). Что сознательно НЕ делалось в первый день: кеш, очереди, мониторинг, документация сверх README — у каждого из этих слоёв должен появиться повод (нагрузка, фоновые задачи, команда). К концу дня сервис отвечает на запросы, покрыт базовыми тестами и ставится одной командой — фундамент, на котором каждый следующий слой из карты достраивается без переписывания предыдущих. Ровно так «скучный стандартный стек» показывает своё главное свойство: он не мешает думать о предметной задаче.
FAQ
Столько инструментов — не перебор для маленького проекта? Карта — меню, не чек-лист: маленькому сервису нужны язык+фреймворк+БД+тесты+ruff, остальное добавляется по мере появления задачи (очереди, кеш, мониторинг — когда заболело).
Что из набора устареет первым? Инструменты периферии (линтеры/упаковщики) меняются — ruff и uv сами пришли на смену зоопарку; ядро (Python, PostgreSQL, pytest, фреймворки) стабильно годами. Инвестиции в понимание границ и принципов не устаревают вовсе.
Как внедрять стек в существующий проект? Не «переписать на новый стек», а добавлять новый код по новым правилам (модуль на FastAPI рядом с легаси, ruff на новые файлы, тесты на новые пути) — постепенность из гайда по типизации обобщается на весь стек.
Где следить за изменениями экосистемы? Первоисточники: блоги релизов (Python, фреймворки), PyPI-страницы зависимостей, ежегодные обзоры (State of Python-опросы); подписки на «новости Python» шумят — релизы миноров и What's New покрывают существенное.
Источники: python.org, Python Packaging Guide, 12factor — ссылки в шапке; навигация по разборам — в тексте.
FAQ
А если команда спорит о стеке неделями? Спор решают ограничения, а не предпочтения: состав команды, характер нагрузки, требования к приватности, срок. Зафиксируйте решение письменно с критериями и датой пересмотра — «выбрали FastAPI, потому что API-first и валидация; пересмотрим, если появится админка» снимает вопрос на год.