Zen of Python

Вышел Pact Python v3 — библиотека для контрактного тестирования микросервисов. Если кратко: Pact позволяет тестировать взаимодействие между сервисами без поднятия всех зависимостей. Consumer описывает, какие запросы он будет делать и какие ответы ожидает, это записывается в JSON-контракт. Потом этот контракт проигрывается против реального provider'а.​ Главное изменение в v3 — переезд с Ruby-бинарников на Rust FFI. Раньше библиотека тащила за собой Ruby-обёртки, теперь всё работает через нативную Rust-библиотеку, скомпилированную под разные платформы. Это дало поддержку Pact Specification v3/v4, нормальные мэтчеры и генераторы данных, async message testing для событийных архитектур.​ Что появилось в API: 🔘Мэтчеры: like(), each_like(), regex(), uuid(), each_key(), each_value()​ 🔘Генераторы тестовых данных 🔘Асинхронные сообщения для Kafka/RabbitMQ и подобных 🔘Улучшенные ошибки при несовпадении контрактов Пример как может выглядеть код:

from pact.v3 import Pact

pact = Pact("consumer", "provider")
(pact
  .upon_receiving("a request for users")
  .with_request("GET", "/users")
  .will_respond_with(200)
  .with_body({"users": like([{"id": 1, "name": "Alice"}])}))

Миграция с v2 потребует изменений — переименовали set_state в state_handler, поменяли сигнатуры message handler'ов. Python 3.8 больше не поддерживается. Код в репо, документация на офф. сайте, установка как обычно pip install pact-python. @zen_of_python

Cookiecutter — это CLI-утилита для генерации проектов из шаблонов. Если вам надоело каждый раз копипастить структуру папок, настраивать pyproject.toml, README и прочую обвязку — инструмент закрывает боль. Работает просто: берёте готовый шаблон (свой или чужой с GitHub), запускаете cookiecutter, отвечаете на вопросы в интерактивном режиме — и получаете готовую структуру проекта с подставленными значениями. Шаблоны используют Jinja2, так что можно делать условную генерацию, циклы и любую логику внутри. Переменные задаются в cookiecutter.json, там же можно указать дефолтные значения и валидацию. Есть хуки для запуска скриптов до и после генерации — например, сразу инициализировать git или установить зависимости. На GitHub уже куча готовых шаблонов: cookiecutter-pypackage для Python-пакетов, cookiecutter-django для Django-проектов, шаблоны для pytest-плагинов и много других. Проект зрелый — 24 тысячи звёзд, почти 300 контрибьюторов, используется в 35 тысячах репозиториев. Работает на Windows, Mac и Linux, поддерживает Python 3.8–3.12. Быстрый старт: pipx install cookiecutter или python -m pip install --user cookiecutter, затем cookiecutter gh:audreyfeldroy/cookiecutter-pypackage — и через пару вопросов у вас готовый Python-пакет со всей структурой. Код в репо. @zen_of_python

Когда между идеей и продом — преград нет! В VK любят решать сложные и масштабные задачи, а ещё — быстро реализовывать идеи. Команда рассказала, каких принципов придерживается в работе и какими результатами гордится. Переходите по ссылке, там много интересного! Это #партнёрский пост

Автор два года пилил свою библиотеку для Dependency Injection в Python и наконец выкатил её в продакшен-ready состоянии. Называется python-injection, и главная фишка — минимум конфигурации и максимум простоты.​ Работает всё на декораторах и type hints: вешаете @injectable или @singleton на класс, а потом @inject на функцию — и зависимости резолвятся автоматически по аннотациям типов. Поддерживаются четыре типа времени жизни: transient (новый инстанс каждый раз), singleton, constant (для конфигов) и scoped (привязка к контексту). Есть поддержка async, профили для переключения зависимостей между окружениями и scoped-зависимости через context manager.​ Комьюнити сравнивает проект с dependency-injector и другими решениями. Автор отмечает, что его подход менее инвазивный: если захотите избавиться от библиотеки, достаточно убрать декораторы — код останется рабочим. Из минусов — нужно не забывать импортировать модули, где объявлены декораторы, иначе зависимости не зарегистрируются. Работает только на Python 3.12+.​ Установка стандартная: pip install python-injection. Дальше импортируете нужные декораторы из injection и размечаете классы и функции.​ Код в репо. @zen_of_python

Вышла свежая либа для авторизации в Python — PyPermission. Это небольшая RBAC‑библиотека, которая реализует классическую модель ролей по NIST: есть роли, есть права, права можно складывать в иерархии (chat.*, chat.global, ticket.close.own и т.д.), а дальше вы просто спрашиваете у системы: «есть ли у пользователя Х такое‑то право?».​ Идея в том, чтобы описать все разрешения декларативно, а не размазывать if role == ... по коду. Вы заводите PermissionNode`‑класс с перечислением прав, настраиваете `Authority и храните роли с привязанными пользователями либо в JSON/YAML‑файле, либо в базе через SQLAlchemy — PyPermission сам разрулит наследование ролей и проверку доступа через метод subject_has_permission.​ Устанавливается всё обычным pip install PyPermission, а если нужен конкретный бэкенд хранения, то PyPermission[sqlalchemy] или PyPermission[yaml]. Авторы честно помечают проект как alpha: API ещё могут поломать, но уже есть рабочие примеры, тесты и заготовленная документация, так что если вы как раз думаете, как аккуратно оформить права в своём сервисе или админке на Python, это хороший кандидат попробовать. Код в репо, отдельно документация. @zen_of_python

Python 2025: что посмотреть В этом году питон‑коммьюнити много говорит про развитие разработчиков, виртуальные окружения, AST‑магию, большие данные и новые паттерны RAG. Для бэкграунда очень советую документалку Python: The Documentary и Q&A с Гвидо и компанией. Про развитие и карьеру 🔘Выйти из «ада туториалов» — как перестать смотреть бесконечные курсы и начать делать свои проекты (с помощью ИИ тоже). 🔘Менторинг в обе стороны — как помогать другим и параллельно прокачивать себя, не закапываясь в синдром самозванца. 🔘Design Pressure — про то, как инструменты и процессы незаметно гнут архитектуру кода, и что с этим делать. Инструменты, AST и железо 🔘Виртуальные окружения прошлого, настоящего и будущего (и куда движутся uv‑подобные тулзы). 🔘AST‑парсинг для ускорения библиотек и переписывания кода до попадания в C‑расширения. 🔘Как не умереть от огромных JSON‑ов: стриминг, JSON Lines и более компактные форматы. 🔘Чип PyXL, который гоняет Python прямо в железе и даёт серьёзный буст без переписывания кода. Данные, RAG и аналитика 🔘Narwhals: один API поверх Polars, DuckDB, PyArrow, pandas и cuDF — меньше if‑ов, больше совместимости. 🔘DuckDB как способ приручить «зоопарк файлов» и собрать нормальные пайплайны. 🔘Structured RAG is better than RAG от Гвидо — как структурированный RAG делает ответы точнее и даёт долгую память ИИ, плюс новая Python‑библиотека под это. 🔘Футбол‑аналитика на Polars, Keras и GNN: превращаем координаты игроков в метрики и модели уровня профклубов. @zen_of_python

Вышел Hatch v1.16.0 с поддержкой монорепозиториев, dependency groups по PEP 735 и генерацией SBOM. Если не знакомы с этим инструментом, Hatch — это современный менеджер проектов на Python, который объединяет управление виртуальными окружениями, зависимостями, сборку пакетов и публикацию в PyPI. В общем, всё в одном месте: от создания нового проекта до его релиза.​ 1️⃣Главная фича релиза — workspaces, которые позволяют работать с монорепами. Раньше если у вас было несколько связанных пакетов в одном репозитории, приходилось городить костыли или переходить на другие инструменты. Теперь можно просто указать в pyproject.toml список пакетов через workspace.members, и Hatch автоматически установит их все в одно окружение в режиме editable. Работает как workspace в Cargo или npm — все пакеты в одном виртуальном окружении, IDE видит их все, pytest может импортировать что угодно.​ 3️⃣Второе нововведение — поддержка PEP 735 dependency groups. Это стандартизированный способ группировать зависимости прямо в pyproject.toml, не создавая кучу отдельных файлов типа requirements-dev.txt, requirements-test.txt и так далее. Теперь можно держать всё в одном месте: группы для разработки, тестирования, линтеров и т.д. Причём это именно стандарт, а не очередное проприетарное решение одного инструмента.​ 3️⃣Также добавили опцию sbom-files для включения Software Bill of Materials в пакеты. SBOM — это, по сути, полная спецификация всех компонентов и зависимостей вашего софта, что становится важным для безопасности и compliance. Если нужно отслеживать, что именно входит в ваш пакет и откуда оно взялось, теперь можно это делать стандартным способом. Код в репо, или вот прямая ссылка на новый релиз. @zen_of_python

Свежий доклад «Building Data Visualisations in Python in Minutes» — лайвкод‑видео про то, как быстро накидать визуализацию данных на чистом Python с помощью Streamlit, без REST‑сервисов и отдельного фронтенда. Идея простая: у тебя уже есть серверный код, который ходит в базы, файлы и API, а Streamlit позволяет превратить это в аккуратную веб‑страницу с графиками.​​ Автор начинает вообще с нуля: 🔘ставит Streamlit, пишет минимальный скрипт с st.title и выводом таблицы данных в браузере; 🔘подключает Pandas, подгружает датасет, строит базовые графики в один‑два вызова API Streamlit; 🔘добавляет интерактивность через st.selectbox и кеширование данных декоратором, чтобы всё работало быстро. Главная мысль: для внутренних дашбордов и чтобы быстро посмотреть, что вообще в данных происходит, часто достаточно одного Python‑файла со Streamlit, который можно запускать локально или на внутреннем сервере. Это сильно проще, чем поднимать BI, тащить React или городить отдельный сервис только ради пары графиков. Оригинал на YT, если вам там удобнее смотреть. @zen_of_python

Канал по нейронкам, который часто пересекается с Python по темам: @neuro_channel Веду его тоже я, так что если вам нравятся посты в Zen of Python в последние недели, то буду рад видеть вас и в «Нейроканале». Три примечательных поста: 1️⃣Про утилиту, которая автоматически снимает цензуру (safety alignment) с трансформерных языковых моделей без дообучения и ручного тюнинга. 3️⃣Разбор сборки GPT‑OSS с нуля на чистом Python, без PyTorch и без GPU: последовательно с объяснениями от Softmax и RMSNorm до Grouped Query Attention. 3️⃣Залипательный ролик с анимацией, как нейросеть «думает» в латентном пространстве в процессе обучение распознаванию цифр. Плюс новости о выходе новых моделей, чтобы не пропустить ничего важного. Про ту же Kimi K2 я писал ещё 7го ноября, до того как это стало мейнстримом. Сейчас вон даже в Perplexity добавили её, рядом с GPT 5.1, хотя это открытая модель. @zen_of_python

Есть готовый шаблон FastAPI‑NiceGUI‑Template: фуллстек‑проект целиком на Python с FastAPI на бэкенде, NiceGUI на фронтенде, PostgreSQL в базе и SQLModel в качестве ORM. Он даёт асинхронный API c Pydantic‑валидацией, серверный компонентный UI, работу с БД через Docker Compose и уже настроенную JWT‑аутентификацию.​ Основные фичи:​ 🔘CRUD по сущностям (items); 🔘пользователи с ролями (обычный и суперюзер) и разным уровнем доступа; 🔘динамический UI, который подстраивается под права залогиненного пользователя; 🔘автодоки API через Swagger UI и ReDoc.​ Использовать шаблон удобно, когда нужно быстро собрать внутреннюю админку, дашборд или демо для ML/данных и при этом остаться в одном стеке на Python, без отдельного React/Vue‑фронта и Node.js‑сборки. Для старта достаточно склонировать проект, поднять PostgreSQL через Docker Compose и запустить приложение. Код в репо, подробнее в блоге автора шаблона, на видео демо. @zen_of_python

На реддите обсуждают кто какую библиотеку использует для отрисовки графиков в Python. Сделал краткую выжимку и подборку библиотек: 🔘Matplotlib — базовый стандарт; 🔘Bokeh — интерактивные графики и дашборды в браузере; 🔘Plotly.py — интерактивные 2D/3D‑графики и отчёты; 🔘Seaborn — красивые статистические графики поверх Matplotlib; 🔘Plotnine — ggplot2‑подобный, декларативный стиль построения графиков; 🔘HoloViews — «данные сначала», декларативные интерактивные визуализации; 🔘hvPlot — интерактивный .hvplot() для pandas/dask/xarray. На картинке сравнение по количеству звёзд на гитхабе. В самом треде для интерактивных графиков с зумом/hover/tooltip чаще всего советуют Plotly и Bokeh, а Matplotlib если хватает статических картинок. @zen_of_python

Новый инструмент для поиска мертвого кода в Python-проектах, называется Skylos. Автор заявляет проблему: статические анализаторы часто ругаются на вещи, которые на самом деле используются — например, роуты или хендлеры, которые вызываются извне. И пытается её решить через сканер, который учитывает специфику фреймворков. Skylos понимает, что функция с декоратором @app.route может быть вызвана HTTP-запросом, даже если в коде она нигде не вызывается напрямую. Использует систему confidence levels (0-100) — чем ниже значение, тем больше потенциально мертвого кода покажет, включая роуты и хелперы. Как работает Анализирует AST, находит неиспользуемые функции, классы, импорты. Для веб-фреймворков применяет пониженный confidence (по умолчанию 60, для роутов — 20). Тестовые файлы исключает автоматически, потому что их вызовы не очевидны статически. Можно запускать в интерактивном режиме и выбирать, что удалять — использует LibCST, поэтому правильно обрабатывает многострочные импорты, алиасы, декораторы и async-функции. Запуск

pip install skylos
skylos /path/to/project           # базовый анализ
skylos --confidence 20 app.py     # показать роуты
skylos --interactive /project     # выбрать, что удалить
skylos run                        # веб-интерфейс на localhost:5090

В выдаче — тип находки, confidence score, местоположение. Результаты в benchmarks: быстрее Vulture, лучше recall, чем у Flake8/Ruff. Но как и любой статический анализатор, не ловит getattr() или динамические импорты. Код в репо, на картинке пример выдачи результатов анализа. Есть также плагин для VS Code. @zen_of_python

Pyrefly дорос до беты. Это быстрый type checker и языковой сервер для Python, написанный на Rust: он анализирует типы в проекте и одновременно обслуживает IDE-фичи вроде перехода к определению, подсветки типов и поиска по символам. Подходит, если вы активно используете type hints и хотите получать постоянную проверку типов без ощутимых тормозов даже на больших кодовых базах.​ Быстрый старт в проекте выглядит так:

pip install pyrefly
pyrefly init
pyrefly check --summarize-errors

pyrefly init создаст или обновит конфиг (pyproject.toml или pyrefly.toml), а pyrefly check прогонит типизацию по проекту и покажет сводку ошибок.​ Простейший пример, который Pyrefly сразу подсветит:

def add(a: int, b: int) -> int:
    return str(a + b)

Аннотация говорит, что функция возвращает int, но фактически возвращается str, и Pyrefly отметит это как ошибку типов. Дальше можно подключить его как сервер языка в редакторе (через LSP или готовое расширение) и получать те же проверки прямо во время набора кода. Статус беты говорит, что в принципе уже можно начинать использовать в своих проектах. Если уже пробовали — поделитесь мнением в комментариях, пожалуйста. @zen_of_python

pymupdf4llm-C — извлекатель текста из PDF, написанный на C для скорости работы. Обходит PDF-страницы и сериализует блоки в структурированный JSON. Есть безопасные биндинги для Python и Rust, без сырых указателей. Установка через pip: pip install pymupdf4llm-c или cargo: cargo add pymupdf4llm-c. Для каждой страницы создается JSON с массивом блоков:

[
  {
    "type": "paragraph|heading|table|list|figure",
    "text": "content",
    "bbox": [x0, y0, x1, y1],
    "font_size": 11.0,
    "font_weight": "normal",
    "page_number": 0
  }
]

Для таблиц добавляются row_count, col_count, confidence. Координаты в PDF points, типы блоков для семантической обработки. Как использовать

from pymupdf4llm_c import to_json

# В память
results = to_json("report.pdf", collect=True)
for page in results:
    for block in page:
        if block['type'] == 'table':
            process_table(block)  # свой код для таблиц

Можно писать в файлы: to_json(pdf_path, output_dir=Path("json")). Для Rust есть to_json_collect() и extract_page_json(). Полезно, когда: — требуется предсказуемая структура для векторных баз; — нужно различать заголовки, списки, таблицы при чанкинге; — скорость критична: C-реализация быстрее Python-аналогов; — работаешь с документами, где важна иерархия и расположение элементов. Перед использованием нужно собрать: ./build.sh. Проект свежий, но рабочий. Код в репо. @zen_of_python

Шаблон для ультра-строгих Python‑проектов — что‑то вроде --strict из TypeScript, но на стеке uv + ruff + basedpyright. Идея простая: вместо того, чтобы каждый раз настраивать линтеры, типизацию и менеджер окружений вручную, вы копируете готовый pyproject.toml и сразу получаете очень агрессивные правила по стилю и типам.​ В этом шаблоне uv отвечает за управление проектом и зависимостями, ruff — за линтинг и форматирование, а basedpyright — за строгую статическую типизацию с максимальным количеством включённых проверок. Забрать можно в репозитории, там же инструкции по использованию. Для новых проектов просто копируете pyproject.toml, меняете секцию [project] под себя, создаёте src/your_package и tests/. Затем установка:

uv venv
.venv\Scripts\activate  # Windows
# или source .venv/bin/activate

uv pip install -e ".[dev]"

И далее просто пользуетесь по необходимости:

uv run ruff format .
uv run ruff check . --fix
uv run basedpyright
uv run pytest

Такой сетап хорошо заходит, если вы любите, когда инструменты сразу ломают билд за любые подозрительные места: неописанные типы, мёртвый код, неиспользуемые импорты, странные конструкции и т.п. Из минусов — порог входа выше: придётся либо писать типы везде, либо постоянно удовлетворять строгим линт‑правилам, но для долгоживущих библиотек и сервисов это может сильно окупиться. @zen_of_python

Сейчас обсуждается интересный pre‑PEP о внедрении Rust в CPython, с перспективой сделать Rust обязательной зависимостью при сборке в Python 3.17 после переходного периода в 3.15–3.16. В черновике расписан план: в 3.15 — предупреждение при сборке без Rust, в 3.16 — сборка без Rust только с явным флагом, в 3.17 — Rust может стать обязательным. Зачем это нужно по версии авторов: безопасность памяти и потоков (важно на пути к free‑threaded Python), возможность писать быстрые части стандартной библиотеки на Rust. Есть референс‑имплементация: модуль _base64 на Rust, показывающий ускорение относительно C‑версии, и зафиксирован план FFI через новый crate cpython‑sys для доступа к C‑API CPython с минимальными unsafe‑участками.​ @zen_of_python

Свежий гайд от CodSpeed про то, как по‑нормальному бенчмаркать Python‑код, а не просто крутить timeit в REPL. Автор разбирает, чем отличается разовая прикидка скорости от «продакшен‑бенчмарков», которые гоняются в CI и ловят регрессии по перформансу между коммитами.​ Фокус на подходе через тесты: пишете бенчмарки как pytest‑тесты, помечаете их маркером или используете benchmark‑фикстуру, а дальше CodSpeed через pytest-codspeed и GitHub Actions (или другой CI) автоматически собирает результаты, строит историю и подсвечивает, где вы случайно замедлили код. Плюс есть кейсы вроде параллельного прогонов, шардинга бенчей по нескольким CI‑джобам и интеграции в существующий пайплайн без переписывания уже имеющихся pytest-benchmark тестов. Сам инструмент платный, но до 5 человек для коммерческих проектов доступен без проблем. Для опенсорса без ограничений. @zen_of_python

T-строки в Python — новая техника форматирования, которая появилась в 3.14 и стала пятой в списке после %, str.format, string.Template и f-строк. Синтаксис очень похож на f-строки (те же {} и выражения), но результатом выражения t"..." будет уже не str, а объект шаблона.​ Главное отличие: t-строка сама по себе не делает готовую строку, а возвращает объект Template, внутри которого по отдельности лежат куски текста и интерполяции со всеми их метаданными. Это даёт библиотекам возможность сначала пройтись по этим частям (экранировать, валидировать, форматировать), а уже потом собирать финальный вывод.​ Из-за этого t-строки полезны в первую очередь авторам библиотек: логированию, шаблонизаторам, SQL/HTML-обёрткам и любому коду, где хочется контролировать интерполяцию до склейки в строку. Для обычного прикладного кода ничего не меняется — продолжаете использовать f-строки, пока конкретная библиотека явно не попросит передать ей t-строку вместо готового текста. Нырнуть поглубже можно в статье или на видео к посту. @zen_of_python

Обвязка вокруг SQLAlchemy Core — sqla-fancy-core. Это не очередной ORM, а надстройка для тех, кто любит писать запросы сам, но хочет строгую типизацию, поддержку асинхронности и понятные транзакции без «магии» сессий. Главная фишка — другой способ описывать таблицы вместо table.c.column, который нормально дружит с проверкой типов и делает код понятнее. Плюс поверх движка добавлены обёртки и декораторы: они берут на себя создание подключений и управление транзакциями. Пример:

import sqlalchemy as sa
from sqla_fancy_core import TableBuilder

tb = TableBuilder()

class Author:
    id = tb.auto_id()
    name = tb.string("name")
    created_at = tb.created_at()
    updated_at = tb.updated_at()

    Table = tb("author")

Проект задуман под продакшен: для тех, кто хочет конструктор запросов вместо ORM, но без потери читаемости и безопасности. По словам автора, в отличие от Peewee тут есть аннотации типов и официальная работа с async, Piccolo менее гибкий и сильно навязан по архитектуре, а Pypika не защищает от SQL‑инъекций по умолчанию. В итоге это просто способ сделать SQLAlchemy Core чуть более строгим и удобным, не меняя стек целиком. Есть отдельное демо по использованию. @zen_of_python

Таков путь