🤷 Какой Python-фреймворк выбрать: Django, Flask или FastAPI?

Команда Python for Devs подготовила перевод статьи о том, какой фреймворк выбрать для веб-разработки на Python: Django, Flask или FastAPI.

Django берёт надёжностью и готовой функциональностью, Flask — гибкостью и минимализмом, FastAPI — скоростью и современными возможностями.

📚 Подробности на Хабр: https://habr.com/ru/articles/944708/

✨ Меньше магии, больше кода: мой способ писать Django views

Команда Python for Devs подготовила перевод статьи о том, как автор выбирает способ написания представлений в Django.

Он считает, что обобщённые классовые представления (CBV) скрывают слишком много магии, усложняют чтение кода и отладку. Вместо них он использует базовый View, чтобы сохранять контроль, но при этом избегать громоздких if в функциях.

А вы как пишете свои представления — на функциях, CBV или тоже предпочитаете «чистый» View?

📚 Подробности на Хабр: https://habr.com/ru/articles/946734/

🔝 Топ-6 Python-библиотек для визуализации

Matplotlib, seaborn, Plotly, Altair, Pygal и Bokeh — у каждой свои сильные и слабые стороны: от академических статичных графиков до интерактивных дашбордов для бизнеса.

Выбираем самую подходящую для различных кейсов.

📚 Подробности на Хабр: https://habr.com/ru/articles/946750/

🏆 Python разрывает конкурентов — 26% рейтинга!

Python уверенно №1 в TIOBE Index с огромным отрывом: 25.98% (+5.81% за год). Это почти втрое больше, чем у ближайшего конкурента C++ (8.8%).

Интересно, что ещё в 2010 Python был на 7-м месте, а в 2000 — аж на 23-м. Сегодня это де-факто язык №1 для науки о данных, автоматизации, AI и обучения программированию.

За счёт простого синтаксиса и тонны библиотек Python остаётся идеальным входом в программирование — от скриптов до ML-моделей.

Источник.

#news@python_for_devs

😲 Нововведения Python 3.14: автодополнение и подсветка синтаксиса в REPL

В новой статье узнайте про одно из нововведений Python 3.14, которое упрощает работу с Python за пределами IDE.

Теперь автодополнение и подсветка синтаксиса работают прямо в терминале, а цветовую тему можно настроить под себя.

📚 Подробности на Хабр: https://habr.com/ru/articles/948852/

🧩 PEP 804: как связать внешние зависимости с вашим пакетным миром

Если вы собираете Python-пакет с нативными расширениями или завязками на системные библиотеки (zlib, OpenBLAS, компиляторы, ImageMagick и т. п.), вы точно сталкивались с болью: «pip ругнулся, а что именно надо установить — непонятно».

PEP 804 закрывает эту дыру: теперь инструменты понимают внешние зависимости из вашего pyproject.toml (в формате DepURL из PEP 725) и умеют карточно их с пакетами целевой экосистемы (Ubuntu, Fedora, Homebrew, conda-forge, Nix, Spack и т. д.). В идеале — даже показывать готовую команду установки.

Сценарий: вы ставите пакет, он не собирается из-за отсутствия g++ и zlib. Вместо «гугли сам» вы видите аккуратный список для вашей системы: sudo apt install g++ zlib1g zlib1g-dev. А если вы предпочитаете conda — получите mamba install cxx-compiler zlib.

Когда внешние зависимости не формализованы, ломается все подряд:
🟣 Сборка падает: у разных дистрибутивов разные имена одних и тех же пакетов (zlib1g-dev, zlib-devel, libz), а инструкции в README устаревают быстрее, чем хотелось бы.
🟣 Документация зарастает мхом: сложно поддерживать в актуальном состоянии команды для 5–10 экосистем одновременно.
🟣 CI/релизы с задержками: «оно у меня работало» превращается в рулетку — особенно с чужим Docker-образом, или отличной от вашей OS.
🟣 Анализ зависимостей страдает: внешние требования не видны инструментам, отчего ломаются деревья зависимостей и предсказуемость обновлений.

PEP 804 нацелен искоренить эти проблемы. Вместо «надеемся, что пользователь догадается» — центральный реестр имен + прозрачные сопоставления для конкретных экосистем, поддерживаемые самими экосистемами.

Ниже — минимальный, но рабочий «скелет», который можно взять и внедрить сегодня.

Шаг 1. Опишите внешние зависимости в pyproject.toml

Раздел [external] — это ваш чек-лист для системных/не-PyPI зависимостей. Идентификаторы — это DepURL из PEP 725: dep:generic/... для конкретных библиотек и dep:virtual/... для «ролей» (например, компилятор C++).

[build-system]
build-backend = "mesonpy"
requires = ["meson-python>=0.13.1", "pybind11>=2.10.4"]

[external]
# Что нужно для сборки (toolchain, заголовки)
build-requires = [
  "dep:virtual/compiler/cxx",
]

# Что нужно для линковки/исполнения
host-requires = [
  "dep:generic/zlib",
]

Что это дает: любой инструмент, понимающий PEP 804/725, может на входе получить DepURL и на выходе — список пакетов для вашей ОС/менеджера пакетов.

Шаг 2. Валидируйте DepURL-ы локально

Подтяните тул, который умеет читать [external], валидировать записи и предлагать каноничные идентификаторы. Пример с условным pyproject-external:

python -m pyproject_external show --validate .

Если вы промахнулись (написали dep:virtual/compiler/cpp вместо cxx), получите подсказку вида:

Did you mean 'dep:virtual/compiler/cxx'?

Шаг 3. Получайте команды установки для вашей платформы

То, ради чего все затевалось. Покажите маппинг под «авто-определенную» экосистему (например, Ubuntu + apt) или явно выберите нужную (conda-forge + mamba/pixi):

# Показать внешние зависимости как DepURL
python -m pyproject_external show .

# Показать уже сопоставленные имена пакетов
python -m pyproject_external show --output=mapped .

# Сгенерировать команду установки
python -m pyproject_external show --output=command .
# Пример вывода:
# sudo apt install --yes g++ zlib1g zlib1g-dev python3

Подробнее: PEP 804 — An external dependency registry and name mapping mechanism: peps.python.org/pep-0804/.