Zen of Python

Осенью нас ждёт Python 3.15, набор фич для него уже заморожен в бете. Заглянул, что там приедет, и нашёл пару вещей, которые поменяют привычки. Самое заметное: явные ленивые импорты (PEP 810). Появляется ключевое слово lazy. Модуль пишется в импорте как обычно, но реально подгружается только при первом обращении.

lazy import json
lazy from pathlib import Path

print("старт")  # json и pathlib ещё не загружены
data = json.loads('{"ok": true}')  # здесь json наконец подгружается

Раньше ради быстрого старта тяжёлые импорты прятали внутрь функций. Теперь их можно держать наверху файла, как и положено, без платы за импорт при запуске. Есть и глобальные переключатели: флаг -X lazy_imports и переменная окружения, если хочется включить лень разом. И это не воскрешение отклонённого когда-то PEP 690, механизм тут другой и явный. Второе приятное: встроенный frozendict (PEP 814). Неизменяемый и хешируемый словарь прямо в языке, без импортов. То же, чем frozenset является для set.

config = frozendict({"debug": True, "retries": 3})
# поменять значение уже нельзя, будет TypeError

Ещё одно: PEP 661 даёт штатный способ делать sentinel-значения вместо самодельных MISSING = object(). Теперь это нормальный механизм с человеческим repr и поддержкой в аннотациях типов. Под капотом тоже движение: переработанный JIT даёт около 8-9% на Linux x86-64, интерпретатор с tail-call приехал и на Windows (там плюс 15-20%), появился стабильный ABI для free-threaded сборок. Финальный 3.15 ждём осенью, но облик версии уже ясен. Лично я больше всего жду lazy import: сколько раз приходилось прятать импорты в функции ради быстрого CLI. А вы ждёте 3.15 или пока сидите на чём-то постарше? @zen_of_python

Попалось обсуждение про опенсорс. Мейнтейнер описывает ситуацию: кто-то форкает репозиторий, ссылается в коммитах на его issue — это приятно, человек заинтересовался. А открываешь ветку, и там чистый ИИ-слоп. Файлы свалены в корень вместо src, тесты с print вместо pytest (хотя в CONTRIBUTING всё расписано), импорты вида from mylib import Foo, Bar, которых в коде и документации никогда не было. Сверху сабклассы от этих галлюцинированных типов, разобрать невозможно. Отдельная деталь: у автора такого PR обычно куча форков других репозиториев, и везде он охотится за меткой good first issue. Похоже на сбор очков на GitHub, а не на желание реально закрыть задачу. Отсюда вопрос: стоит ли тратить силы на честное ревью и как закрыть PR, не отпугнув нормальных будущих контрибьюторов. Что советуют бывалые мейнтейнеры: 🔘Просто закрыть и заблокировать. Самый частый ответ. К остальным это не враждебно: либо человек игнорит правила проекта, либо приносит код без ценности. И то и другое повод закрыть. 🔘 Завести метку вроде «doesn't follow contribution rules» и объяснить её в гайдлайнах. Тогда на закрытие уходит три клика, а если вернётся живой человек и поправит PR, это уже сигнал, что стоит посмотреть. 🔘 Поднять минимальный порог через CI. ruff, mypy или basedpyright, pytest с требованием покрытия, проверка докстрингов. Линтеры отсекают мусор автоматически, ещё до человеческого ревью. 🔘 Не закрывать вслепую каждый случай. Люди с неродным английским всё чаще прогоняют описание и доки через ИИ. Если контрибьюция небольшая, есть смысл быстро глянуть сам код. Был и спор про AGENTS.md. Одни считают, что инструкции для агента поднимают качество PR. Другие, что само наличие файла как бы говорит «здесь рады ИИ-коду» и только притягивает слоп. А вы как с этим справляетесь, если ведёте свои репозитории? @zen_of_python

PyPy 7.3.23 стал доступен для скачивания, а PyPy описала релиз как bugfix-обновление. Напомню, PyPy — альтернативный интерпретатор Python с JIT. Его обычно пробуют там, где много долгоживущего CPU-bound кода на чистом Python и хочется ускорения без переписывания на C. Что важно в 7.3.23: 🔘убрали ложные warning'и про неиспользованные корутины при доступе к cr_frame; 🔘починили множественное наследование для смешанных Python/C-extension типов, включая сценарии вокруг pybind11 и cpyext; 🔘PyPy3.11 теперь идёт со стандартной библиотекой CPython 3.11.15; 🔘дизассемблер стал ближе к CPython: интерпретатор перешёл на exception tables вместо отдельных opcodes. На скорость это пока не влияет. Если вы уже используете PyPy, то обновление стоит поставить, API совместим с линейкой 7.3. Если только думаете попробовать — начните с прогона тестов на PyPy3.11 и проверки зависимостей. PyPy лучше всего раскрывается на чистом Python-коде. В проектах, где основная нагрузка уходит в NumPy, pandas, torch или другие C-расширения, прирост может быть совсем другим. @zen_of_python

Наткнулся тут на обсуждение, которое мне тоже периодически приходит в голову: стоит ли использовать uv, если OpenAI покупает Astral. Напомню, Astral это те ребята, которые сделали uv, ruff и ty, которые мы так любим. Короткий вывод: для новых Python-проектов uv всё ещё выглядит самым практичным выбором. Почему разработчики так за него держатся: — uv закрывает сразу несколько бытовых задач: ставит Python-версии, создаёт venv, ставит зависимости, фиксирует lockfile, запускает команды в окружении и заменяет часть сценариев pip, pip-tools, pipx, poetry и pyenv. Типичный flow становится проще:

uv init
uv add fastapi
uv run app.py
uv sync --frozen

Риск с OpenAI тут скорее управленческий, а не технический. Важно смотреть на лицензию, телеметрию, темп релизов и то, останется ли core-разработка открытой. На практике же зависимости живут в стандартном pyproject.toml, а Python уже движется к стандартному lockfile через PEP 751 / pylock.toml, так что миграция с uv должна быть проще, чем с более закрытых форматов. То есть вопрос скорее не про то, использовать ли uv, а о том как использовать его без религии и без лишней привязки к одному владельцу. А вы как думаете? Продолжаем жить на uv, всё норм?

В Long Beach на PyCon US 2026 14 мая прошёл Typing Summit: четыре часа, восемь докладов, один трек. Несколько моментов с саммита. Гвидо ван Россум открыл саммит докладом про то, что правило PEP 484 «никакого нового синтаксиса для типов» де-факто давно нарушено: TypedDict, ParamSpec, оператор type и прочее. Его аргумент: пора признать это формально и выбирать приоритеты по реальной боли пользователей. Опирался на Python Typing Survey 2025. Дуглас Креагер из Astral (его слайд гласил «an OpenAI joint») показал девятистрочный пример, на котором все продакшен-чекеры (mypy, pyright, pyre, Pyrefly, ty) дают неверный ответ:

def choose[A](a1: A, a2: A) -> A:
    return random.choice([a1, a2])

def partial[X, Y, Z](fn: Callable[[X, Y], Z], x: X) -> Callable[[Y], Z]: ...

p = partial(choose, None)
p(2)         # все говорят: ошибка, 2 не None
p("hello")   # то же самое

Прямой вызов choose(None, 2) работает корректно: A решается в None | Literal[2]. После применения partial система ломается. Креагер предлагает другую стратегию: тянуть весь набор констрейнтов как отложенный обобщённый тип, без преждевременной подстановки. ty переезжает на этот подход, внутри используется тернарная структура BDD (двоичные решающие диаграммы с третьим «неопределённым» ребром). Коннер Нильсен из команды Pyrefly доложил результаты экспериментов с ИИ-агентами. Если код хорошо типизирован и type checker подключён к агенту через обёртку с циклом «думай, действуй, наблюдай»: — Доля успешных решений на внутренних бенчмарках команды поднялась с 79,6 до 83,9 процента. — На 21 процент меньше шагов до решения. — На 14 процентов быстрее по полному времени работы. На слабо типизированном коде из SWE-bench Verified эффекта почти нет. Type checker ловит ошибки в соседних с задачей файлах, и агент уходит чинить их вместо основной задачи. Наблюдение по моделям: Claude Sonnet 4.5 чинит каждую ошибку, GPT-5 codex игнорирует типы, пока обёртка насильно их не подсунет. Ещё были доклады про intersection types (Jelle Zijlstra), PEP 827 от Vercel про conditional и mapped types по образцу TypeScript, tensor-shape типы в Pyrefly, и формализация подмножества Python в Lean 4. Полный обзор здесь: https://bernat.tech/posts/pycon-us-2026-typing-summit-recap/ @zen_of_python (теперь в VK и Max)

vLLM-инференс в облаке без собственной инфраструктуры Selectel запустил Foundation Models Catalog — управляемый сервис, где вы выбираете модель из каталога, а провайдер берёт на себя GPU, масштабирование и наблюдаемость. Движок под капотом: vLLM, питоновская библиотека поверх PyTorch, которую сейчас называют производственным стандартом для инференса. Что это даёт на практике: вместо того чтобы поднимать свой vLLM-сервер, арендовать GPU и настраивать мониторинг, вы обращаетесь к уже готовому OpenAI-совместимому эндпоинту через openai-клиент или requests. Код тот же, что при локальном запуске. Автомасштабирование, логи и метрики включены. В каталоге сейчас IBM Granite, Qwen, DeepSeek, Phi, Mistral; скоро Gemma и Whisper. Оплата пока за вычислительные ресурсы, следующим шагом станет тарификация по токенам. Подробнее на Tproger.

В Python 3.14 в стандартную библиотеку добавили модуль concurrent.interpreters: публичный API для запуска нескольких полноценных интерпретаторов внутри одного процесса. Это финал длинной истории. PEP 554 в 2017 году описал идею, PEP 684 в 2023 дал каждому интерпретатору собственный GIL, и PEP 734, принятый в июне 2025, превратил всё это в стандартный Python-модуль. До 3.14 функционал был доступен только через C API. API ровно такой, какой ожидаешь:

import concurrent.interpreters as interpreters
interp = interpreters.create()
interp.exec('print("Hello from subinterp")')
interp.close()

Каждый интерпретатор изолирован: своя память, свой GIL, свой импорт-кеш. Простые типы передаются через специальный канал без копирования, сложные идут через сериализацию вроде pickle. Что это даёт: — Настоящая многозадачность в одном процессе без multiprocessing. Каждый интерпретатор едет на своём GIL и параллельно работает на отдельном ядре. — Совместимость с asyncio. CPU-bound подзадачи можно гонять в субинтерпретаторах, а сетевой ввод-вывод оставить в основном цикле событий. — Один процесс. Общие файловые дескрипторы, единое управление, без накладных расходов на fork и spawn. У подхода одно главное ограничение: C-расширения. Стабильность под per-interpreter GIL не гарантирована, и многим библиотекам ещё предстоит дозревать. Чистый Python и библиотеки с поддержкой PEP 684 работают, остальные могут падать. PEP 734 и free-threading решают одну задачу разными способами. Free-threading убирает GIL вообще: больше совместимости, меньше изоляции. Sub-interpreters сохраняют GIL на интерпретатор: меньше совместимости, больше изоляции. Похоже, в долгую Python поддержит оба пути. Свежий разбор с примерами и архитектурой: https://alexeev-dev.bearblog.dev/running-multiple-interpreters-in-python-code-incredible-speed/ @zen_of_python (теперь в VK и Max)

Pyrefly — быстрый type checker и language server для Python — добрался до релиза версии 1.0 С бета-версии в ноябре 2025 года прошло больше 60 выпусков. Diagnostics после сохранения ускорились в 2–125 раз, полная проверка крупных проектов — на 20–36%, памяти стало меньше на 40–60%. Соответствие спецификации Python typing выросло с 70% до 90%. Добавили пресеты конфигурации: от отключённых проверок до strict. Для проектов без конфига — автоматический lightweight basic preset, для миграции с mypy и pyright — автоматическая конвертация настроек. Улучшили LSP: Safe Delete, точная навигация, hover cards с богатой информацией. Полная поддержка Jupyter notebooks на уровне обычных .py файлов. Расширили поддержку Django, Pydantic, Pytest. Два новых инструмента для внедрения в существующие кодовые базы: coverage report и baseline files (снимок текущих ошибок, чтобы показывать только новые). Не скажу, что я план фанат, мне больше по душе ty, но они пока что на версии 0.0.35 т.е. сами дают понять, что делают крутую штуку, но в прод рановато. @zen_of_python

Выбор библиотеки для логирования в Python, автор сделал свежий обзор, кратко перескажу. Стандартный logging остаётся базой — им пользуются все фреймворки и библиотеки, и через него проходит интеграция с OpenTelemetry. Но конфигурация через dictConfig не самая удобная, а контекст на уровне запроса приходится прокидывать вручную через contextvars. structlog — главный кандидат на замену. Процессорный pipeline из коробки даёт redaction, enrichment и sampling. contextvars работают через asyncio без дополнительного кода. При этом можно оставить stdlib в качестве backend — весь хэндлер-экосистема сохраняется. По бенчмаркам structlog примерно в 2 раза быстрее stdlib и Loguru: 242k ops/s против 139k и 147k соответственно. Loguru — минимум setup, но ценой глобального логгера без иерархии компонентов. Нет нативной OpenTelemetry-интеграции, только через InterceptHandler в обход. Logbook — legacy от Armin Ronacher. Нет structured JSON из коробки, нет OTel. Для новых проектов не рекомендуется. picologging — drop-in replacement на C от Microsoft, в 4–17 раз быстрее, но проект не поддерживается с 2023 года, нет поддержки Python 3.13+. Не для продакшена. Главный вывод статьи: выбор библиотеки менее важен, чем практики. Structured output, консистентный контекст, правильные уровни и чистота полей — вот что делает логи полезными в production. Если stdlib с python-json-logger работает, не мигрируйте ради миграции. Если boilerplate мешает — берите structlog.

Откуда в России взялись программисты — история, которую вам не рассказывали Если вы думаете, что российский IT начался с нулевых — нет. Всё началось на несколько десятилетий раньше, в закрытых НИИ и институтских подвалах. В конце 1940-х Советскому Союзу понадобились вычислительные машины — моделировать ядерные реакции и считать ракетные траектории вручную было нереально. Учёный Сергей Лебедев построил первую советскую ЭВМ, а потом серию БЭСМ. Пиковая модель, БЭСМ-6, выпускалась почти 20 лет — именно на ней учили программированию в лучших технических вузах. Культура, сложившаяся в условиях жёстких ограничений, никуда не исчезла. Она и стала фундаментом для Яндекса, Контура и всего остального российского бигтеха. Читайте все 7 фактов на Tproger @tproger Читайте также в VK, Max и Дзен

«Хочу в IT, но не знаю куда» — это нормально. Вот тест, который помогает разобраться Тестировщик, системный разработчик, сетевой администратор, инженер по железу — когда только входишь в профессию, все звучит одинаково непонятно. И выбрать направление наугад — не лучший план. YADRO — одна из самых быстрорастущих технологических компаний страны — сделали квиз на основе реальных задач своих стажировок. Семь вопросов без правильных и неправильных ответов: просто выбираете то, что откликается. На выходе — конкретное направление с описанием задач и честной вилкой зарплат после стажировки. Полезно даже не для того, чтобы попасть именно в YADRO — а чтобы понять, в какую сторону вообще смотреть. Пройти квиз: https://tprg.ru/9Dic

Как писать Python-библиотеки в 2026 году — гайд от разработчика, который недавно прошёл этот путь в продакшене. Основной тезис: экосистема Python наконец-то консолидировалась. Вместо десятка разрозненных инструментов теперь можно обойтись экосистемой Astral. Стек: — uv init --lib my-package — проект за одну команду, src-структура, pyproject.toml, .python-version сразу на месте — ruff — линтинг и форматирование в одном флаконе — mypy или ty / pyrefly — типизация (автор рекомендует попробовать все три, uv позволяет быстро переключаться) — pytest + pytest-cov — тесты с coverage — uv run --python 3.12 — тестирование на разных версиях Python без tox и nox — pre-commit + CI — контроль качества до момента коммита и при релизе Ключевой инсайт: uv настолько хорош, что для внутренних библиотек даже не обязательна публикация в PyPI. Можно ставить прямо из git-репозитория: uv add /path/to/my-package, и uv сам разберётся с билдом, кэшем и линковкой. В конце автор разбирает реальные стеки openai-python и polars — оба уже на ruff, но openai ещё на старом билд-инструменте (hatchling через rye), а polars обходит стандартный подход из-за Rust-ядра. Полный гайд: https://stephenlf.dev/blog/python-library-in-2026/

Исследуйте инструменты для разработчиков в системе SourceCraft в новом квесте с космическими призами! https://tprg.ru/nDdZ @zen_of_python

В Python-сообществе обсуждают свежий PEP 831 под названием «Frame Pointers Everywhere». Авторы предлагают начиная с Python 3.15 по умолчанию собирать CPython и все Си/Rust-расширения с включёнными указателями фреймов (frame pointers). Зачем это нужно? Исторически компиляторы (GCC/Clang) для оптимизации вырезают указатели фреймов, освобождая один регистр процессора для вычислений. Проблема в том, что без этих указателей внешние профайлеры (perf, py-spy) и eBPF-тулы не могут нормально размотать стек вызовов. Вы пытаетесь понять, почему тормозит ваш бэкенд, открываете flame-граф, а там вместо нормального трейса — обрывки сишных функций и сломанный стек. PEP 831 предлагает добавлять флаги --fno-omit-frame-pointer --mno-omit-leaf-frame-pointer при сборке как самого интерпретатора, так и всех сторонних пакетов, которые компилируются через sysconfig. Главные тезисы предложения: — Системная наблюдаемость из коробки. Любые профилировщики смогут строить идеальные flame-графы для Python-процессов без костылей. — Нужна поддержка всей экосистемы. Цепочка фреймов работает только если все звенья (CPython, ваши C-экстеншены, библиотеки на Rust) собраны с флагами. Одна библиотека без указателей, и трейс ломается для всего процесса. — Производительность почти не страдает. Авторы замерили падение производительности: в среднем оно составляет менее 2%. А на задачах, сильно нагружающих eval-loop, код парадоксальным образом работает даже на 1–2% быстрее из-за лучшего распределения инструкций в кэше процессора. — Уже протестировано в бою. Все бинарники python-build-standalone (которые под капотом использует тот же uv) уже давно собираются с этими флагами. То есть половина современного питона уже работает с frame pointers, PEP просто хочет сделать это официальным стандартом. Для тех, кому нужен каждый процент перформанса (например, в жёстком числовом дробилове), оставят флаг --without-frame-pointers при сборке интерпретатора. На Windows изменения никак не повлияют, там механизм размотки стека работает иначе и проблем с профайлингом нет. Метрики по производительности на скрине. @zen_of_python (теперь в VK и Max)

Устали от уймы API-ключей и танцев с бубном вокруг OpenAI, Claude и Gemini? Снять эту головную боль может один API-роутер. Разбираемся на Tproger, почему три разных API могут тормозить ваш проект и как подключить GPT-5.4, Claude Sonnet 4.6 и Gemini 3.1 Pro через единую точку входа без переписывания кода. Кратко о содержании: — Что умеет хороший роутер: fallback, балансировка, кеш, единый биллинг. — Пошаговый гайд подключения через одни API на Python и Node.js. — Реальный кейс: мультимодельный бот с авто-переключением за 30 минут. — Подводные камни: контекстные окна, latency, rate limits (и как их обойти). Читать материал: https://tprg.ru/YWhU

Astral берётся за безопасность Python — тот же Ruff-подход, теперь к PyPI Astral запускает аудит зависимостей и обнаружение вредоносных пакетов. Логика железная — uv уже стоит в точке входа миллионов проектов и видит весь граф зависимостей. Грех не проверять. Тайпсквоттинг, малварь в PyPI, пакеты-двойники — не абстрактные угрозы. pip install reqeusts — один символ, и вы узнаёте много нового о supply chain атаках. В Rust, Go и Node подобная инфраструктура существует давно. Python получает её теперь — и, судя по тому, как Astral делали uv и Ruff, делают это они быстро.

Разработчик запустил первый PyPI-пакет repowise (инструмент для автоматической генерации wiki-документации по кодовой базе) и через несколько дней обнаружил три copycat-пакета, выложенных одновременно с идентичным описанием: «base intelligence ahead — performs every dimension». Оказалось, это не просто спам-пустышки. Автор-одиночка форкнул его код (лицензия AGPL-3.0), прогнал через LLM для мелких правок, выложил под тремя разными именами без указания источника и без соблюдения условий лицензии. Два важных тейка из обсуждения в треде: — Про AGPL и AI-генерированный код. Даже если 95% нового пакета написано нейросетью, а вы внесли только 5% оригинального кода, то лицензия оригинала всё равно распространяется на весь форк. Это не меняет юридический статус AGPL. Отдельный спорный момент: код, созданный ИИ не во всех странах защищён авторским правом вообще. — Про PyPI security. Команда безопасности PyPI разобрала репорт за 48 часов. Пакеты были удалены. Жаловаться стоит через форму malware («Report a security vulnerability»), а не через общую поддержку. Параллельно можно отправить DMCA-запрос на GitHub. @zen_of_python (теперь в VK и Max)

Учим LLM работать с файлами локально На Тпрогер вышла пошаговая инструкция о том, как поднять локальную агентную AI‑систему из трёх компонентов: — LibreChat — удобный UI для общения с LLM — MCP‑сервер — стандартный доступ к файлам и инструментам — Langflow — визуальный конструктор для многоступенчатых сценариев (с валидацией и расчётами) Всё работает в изолированной Docker‑сети. Данные никуда не уходят. В статье готовые docker-compose.yml, конфиги librechat.yaml, пример кастомного Python‑компонента для расчётов и таблиц, а также схемы работы каждого этапа.