ArgMan — легковесный менеджер аргументов командной строки для Python. Позиционируется как более простая замена argparse для небольших проектов.

Из коробки поддерживаются позиционные и опциональные параметры, короткие и длинные флаги вроде -v/--verbose, а также хуки для преобразования типов и валидации. Установка стандартная: pip install argman.

Сейчас не поддерживается парсинг из списка строк (не только из sys.argv) — автор обещает, что сначала допилит подкоманды, а затем добавит более универсальный парсинг. Исходники на GitHub, автор активно отвечает и готов вносить правки и дорабатывать.

На картинке к посту пример использования.

@zen_of_python

Гвидо ван Россум рассказал о Structured RAG — подходе, когда мы не просто режем документ на куски и превращаем в векторные эмбединги, а заранее вытаскиваем из текста структурированные «знания» (сущности, типы, действия, связи) и храним их в обычной базе. На этапе запроса вопрос тоже приводится к такому же структурному виду, ищутся совпадения по полям, а при достаточном лимите токенов добавляются исходные фрагменты текста. По словам Гвидо, это даёт более точные ответы, выдерживает длинные диалоги и ускоряет сложные запросы.​

Почему это лучше классического RAG с векторами: векторы громоздки, по большим документам совпадения «размываются», а полнота (recall) заметно проседает; озвучена оценка порядка 60%. В Structured RAG основная работа переносится на этап индексации, поэтому сам поиск получается дешевле и легче масштабируется. Плюс можно делать простые выводы по типам (например, если кто-то указан как artist, то это person), что помогает отвечать на вопросы «кто из людей…».​

На демо Гвидо показывал поиск по скетчам Monty Python и по собственной почте: система умеет пополнять память на лету, так что к фактам и диалогам можно возвращаться спустя время. Эмбеддинги при этом используются минимально — как вспомогательный механизм для синонимов и родственных терминов; а GraphRAG здесь не конкурент, а соседний подход: Structured RAG выигрывает инкрементальной индексацией без тяжёлой кластеризации.​

Код открыт: пакет typeagent уже доступен на PyPI. Исходники лежат в репозитории. Это ранний прототип; для запуска нужен ключ к LLM‑провайдеру (в докладе — OpenAI).

В посте дубляж на русский, оригинал на YT.

@zen_of_python

Статья «Building a CI/CD Pipeline Runner from Scratch in Python»

Автор показал, как собрать с нуля свой мини‑раннер для CI/CD на Python для случаев без доступа к GitHub Actions/GitLab Runner, чтобы понять, что происходит под капотом и запускать пайплайны в изолированных окружениях без облака. Ключевая идея простая: раннер — это оркестратор, который парсит YAML, строит граф зависимостей, запускает задачи в контейнерах, стримит логи и пробрасывает артефакты между задачами.​

Из примеров: классика со стадиями build/test/deploy, где build кладёт сборку в dist/, тесты берут контент из dist/ и запускаются параллельно, а деплой на прод запускается только в ветке main. Артефакты складываются во внутреннюю .pipeline_artifacts и перед каждым шагом подтягиваются по списку нужных задач, при этом рабочая папка монтируется в контейнер, а команды шага объединяются в одну строку shell.​

Такой раннер пригодится для локального теста конфигов или учебных задач, когда хочется гибкости без внешних сервисов. До продакшен уровня остаются распределённое выполнение, кеши зависимостей, матричные сборки, секреты, сервис‑контейнеры и ретраи, но базовая архитектура — парсер, планировщик, исполнитель и менеджер артефактов — уже закрывает основные потребности.

@zen_of_python

С кем знакомятся типичные программисты: 2D-тян или живая девушка?

Согласно недавним исследованиям Vantage Point Counseling Services, треть американцев хотя бы раз состояла в романтических отношениях с ИИ. Появилось даже приложение Loverse для виртуальных знакомств, где вместо реальных людей роль партнёров выполняют чат-боты с искусственным интеллектом.

Мы решили провести своё исследование и выяснить где и с кем сегодня знакомятся пользователи стран СНГ. Пожалуйста, пройдите наш небольшой опрос. Это поможет нашему исследованию.

Пройти опрос.

Все программисты немного Никита

@zen_of_python

Вы знали, что у нас есть канал с хитрыми задачками по Python?

Вот прямо сейчас там в комментариях обсуждаем задачу с подвохом.

Каждый рабочий день по одной задачке с квизом, можно сразу проверить себя. И через час пост с подробным объяснением, почему именно так.

Занятный проект на Python из категории «потому что могу»: Rubiksolver

Коротко: это десктоп-приложение, которое через веб-камеру считывает состояние перемешанного кубика Рубика и показывает пошаговое решение с анимацией в окне на PySide6 с отрисовкой через OpenGL и обработкой изображения в OpenCV. Проект позиционируется как учебный — подойдёт тем, кто хочет понять базовые приёмы компьютерного зрения и графики на практике.​

Сканирование: показываете камере по одной грани по заранее заданным правилам. После скана жмёте Play, чтобы запустить анимацию, или листаете шаги кнопками Previous/Next — так удобно проверять, что распознание и сама сборка идут корректно.​

Установка: клонируете репозиторий, выполняете uv sync для зависимостей и запускаете uv run rubiksolver — автор использует современный менеджер uv, так что установка занимает минимум времени.

Автор отмечает, что на Android встречаются решалки, но чаще всего там состояние кубика приходится вбивать руками, без автосканирования камерой — здесь как раз закрыта эта боль.

@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

T-строки в Python — новая техника форматирования, которая появилась в 3.14 и стала пятой в списке после %, str.format, string.Template и f-строк. Синтаксис очень похож на f-строки (те же {} и выражения), но результатом выражения t"..." будет уже не str, а объект шаблона.​

Главное отличие: t-строка сама по себе не делает готовую строку, а возвращает объект Template, внутри которого по отдельности лежат куски текста и интерполяции со всеми их метаданными. Это даёт библиотекам возможность сначала пройтись по этим частям (экранировать, валидировать, форматировать), а уже потом собирать финальный вывод.​

Из-за этого t-строки полезны в первую очередь авторам библиотек: логированию, шаблонизаторам, SQL/HTML-обёрткам и любому коду, где хочется контролировать интерполяцию до склейки в строку. Для обычного прикладного кода ничего не меняется — продолжаете использовать f-строки, пока конкретная библиотека явно не попросит передать ей t-строку вместо готового текста.

Нырнуть поглубже можно в статье или на видео к посту.

@zen_of_python

Свежий гайд от CodSpeed про то, как по‑нормальному бенчмаркать Python‑код, а не просто крутить timeit в REPL. Автор разбирает, чем отличается разовая прикидка скорости от «продакшен‑бенчмарков», которые гоняются в CI и ловят регрессии по перформансу между коммитами.​

Фокус на подходе через тесты: пишете бенчмарки как pytest‑тесты, помечаете их маркером или используете benchmark‑фикстуру, а дальше CodSpeed через pytest-codspeed и GitHub Actions (или другой CI) автоматически собирает результаты, строит историю и подсвечивает, где вы случайно замедлили код. Плюс есть кейсы вроде параллельного прогонов, шардинга бенчей по нескольким CI‑джобам и интеграции в существующий пайплайн без переписывания уже имеющихся pytest-benchmark тестов.

Сам инструмент платный, но до 5 человек для коммерческих проектов доступен без проблем. Для опенсорса без ограничений.

@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

Шаблон для ультра-строгих 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

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

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

Новый инструмент для поиска мертвого кода в 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