Python в апреле: Packaging Council, GC-реверт, Astral в OpenAI
Python Steering Council принял PEP 772 — у языка появился избранный совет по упаковке. Инкрементальный GC из 3.14 откатывают: память росла до 5x. Astral c uv и Ruff перешла под OpenAI. Что ещё было в Python-экосистеме в апреле.
Новости Tproger
Прошедший месяц в Python-экосистеме оказался редким по плотности институциональных изменений. Python Steering Council 16 апреля принял PEP 772 — у языка впервые появился отдельный избранный совет по упаковке: пять человек с тем же уровнем полномочий, что и сам Steering Council, но узкоспециализированных. В тот же день core-команда откатила инкрементальный сборщик мусора, который ввели в Python 3.14, — продакшен показал рост памяти до 5 раз. А компания Astral со своими uv и Ruff перешла под крыло OpenAI: 126 миллионов скачиваний uv в месяц теперь под чужим контролем.
Разбираем главные события апреля 2026 — что меняется для тех, кто пишет на Python, мейнтейнит библиотеки или поддерживает прод-инфраструктуру.
Главное
Ключевые выводы
PEP 772 принят. Python получил избранный Packaging Council из пяти человек с двухлетними сроками — теперь у решений про pip, setuptools и PyPI есть формальный орган, не зависящий от PyPA.
Инкрементальный GC откатывают. В 3.14.5 и 3.15 вернётся старый поколенческий сборщик. Память на проде росла до 5×, а паузы 26 мс vs 1,3 мс этого не оправдывали.
OpenAI приобрёл Astral. Создатели uv, Ruff и type-checker ty теперь под OpenAI. Лицензии открытые — форк остаётся страховочным механизмом.
PEP 803 принят. Появится abi3t — стабильный ABI для free-threaded билдов, цель Python 3.15. Решает «wheel-explosion» для Cryptography, SciPy, Pydantic.
Python 3.15.0 beta 1. Первая бета и feature-freeze назначены на 5 мая. После этой даты в 3.15 уже не попадут новые PEP-ы.
PEP 772: у Python появился Packaging Council
16 апреля Python Software Foundation и Steering Council одобрили PEP 772 — учреждение Packaging Council из пяти человек, выбираемых голосующими членами PSF. Полномочия совета сравнимы со Steering Council, но узкоспециализированы: стандарты упаковки, инструменты вроде pip и setuptools, эксплуатация PyPI.
До этого момента Python Packaging Authority (PyPA) координировала упаковочные решения неформально, через делегирование от Steering Council по PEP 609. На практике это значило, что любое крупное изменение в pip или PyPI требовало согласования через несколько групп без чёткого мандата. Совет получает прямые полномочия и работает на двухлетних сроках с шахматным переизбранием — две и три позиции ротируются в разных циклах, чтобы сохранять преемственность.
Главное последствие — упаковочные вопросы перестают зависать в комитете. По формулировке PEP, решения принимаются консенсусом, как и в Steering Council, но при необходимости совет может действовать голосованием. На повестке у нового органа уже стоят темы вроде упаковки в эпоху LLM-зависимостей и стандартизации lockfile-формата.
Реверт инкрементального GC в Python 3.14.5
В тот же день, 16 апреля, релиз-менеджер Hugo van Kemenade предложил откатить инкрементальный сборщик мусора, дебютировавший в Python 3.14, и core-команда согласилась. Реверт войдёт в 3.14.5 и 3.15 до feature-freeze.
Тестирование на продакшене у Neil Schemenauer показало интересную картину. Максимальные паузы инкрементального коллектора действительно упали с 26 мс до 1,3 мс — то самое, ради чего его и вводили. Но пиковое потребление памяти выросло до 5× baseline, а суммарное время выполнения задач увеличилось из-за дополнительной бухгалтерии. Для веб-приложений, дата-пайплайнов и батч-задач длинные паузы — не главная проблема. Память — главная.
Необычная часть истории — что ревёрт идёт в патч-релизе 3.14.5. На цикле релиза 3.14 предположение было, что инкрементальный GC обоснован. Откат показывает, что «прошёл бенчмарк-сьют» и «работает в проде» — это не одно и то же. Если ваши деплои на 3.14 жгут заметно больше памяти, чем на 3.13, теперь понятно почему. Core-команда не закрывает инкрементальный подход насовсем — вернуться к нему могут в 3.16, но через полноценный PEP-процесс, который оригинальная реализация пропустила.
OpenAI приобрёл Astral — uv, Ruff и ty переходят к ChatGPT-вендору
В конце марта OpenAI объявил о покупке Astral — компании-разработчика uv, Ruff и type-checker ty. Новость прокатилась по сообществу в апреле, когда разработчики начали считать масштаб сделки. uv в начале года перешагнул отметку в 126 миллионов скачиваний в месяц, Ruff давно стал линтером по умолчанию для существенной доли современных Python-проектов. Перенос обоих инструментов под OpenAI — ощутимый сдвиг в том, кто контролирует критическую инфраструктуру Python.
Реакция Simon Willison — «осторожно-оптимистичная»: команде Astral можно доверять прямо сейчас, но «product+talent acquisition может со временем превратиться в чисто talent-only». Структурная страховка — открытые лицензии: форк остаётся жизнеспособным запасным вариантом, если будущие владельцы решат развернуть стратегию.
Первый полный месяц после поглощения прошёл «скучно в хорошем смысле»: uv выпустил патчи 0.11.3–0.11.7, Ruff — 0.15.9–0.15.11, ни один проект курса не сменил. Если кто-то опасался резкого крена в сторону интеграции только с Codex — этого не произошло. На tproger мы писали ранее о том, как Astral в начале апреля запустила направление безопасности — теперь это инициатива внутри OpenAI.
PEP 803: стабильный ABI для free-threaded Python
PEP 803 приняли 30 марта, цель — Python 3.15. Документ определяет abi3t — отдельный вариант стабильного ABI для free-threaded билдов. Это закрывает «wheel-explosion problem», на которую Cryptography, SciPy и Pydantic жалуются уже больше года.
Сейчас, чтобы расширение работало на free-threaded Python, мейнтейнерам приходится собирать отдельный wheel для каждой минорной версии каждого Python-релиза. Контракт обычного abi3 (собрал один раз — работает на любой 3.x) для free-threaded не работает: у этих билдов разные инварианты по потокобезопасности.
Цена стабильности — PyObject становится непрозрачным под abi3t. Расширения, которые сейчас лезут в поля PyObject напрямую, должны мигрировать на новые accessor-API из PEP 697 и PEP 793. Это реальный рефакторинг, но взамен — один wheel на много версий Python. Картинку дополняет FastAPI 0.136.0 от 16 апреля: теперь у фреймворка есть официальная поддержка Python 3.14t. Инфраструктурный слой для GIL-free Python зреет быстро.
Что ещё стоило бы заметить
- Python 3.15.0 beta 1 — 5 мая. Альфа 8 от 7 апреля стала последней. Бета означает feature-freeze: новые PEP-ы в 3.15 после 5 мая уже не попадут.
- JIT в 3.15 быстрее. На x86-64 Linux замеры показывают +6–7%, на AArch64 macOS — +12–13% по сравнению с tail-calling-интерпретатором из 3.14.
- PEP 829 (черновик). Barry Warsaw предложил
.start-файлы как замену.pthдля startup-хуков пакетов. Старый формат позволяет произвольное исполнение кода при импорте — известный supply-chain-вектор. - Polars 1.40.0 (18 апреля). Streaming-движок дотянули до групповых AsOf-join, статистики (
cov,corr,skew,kurtosis,entropy) иstrptime; добавили lock-free memory manager со spill-to-disk. - Starlette 1.0 (22 марта). ASGI-фундамент FastAPI наконец стабилен: API теперь не сломается без мажорного релиза.
- Gemma 4 day-one в Python. 2 апреля Google открыл веса (2B/4B/31B + 26B MoE). Transformers 5.5.0, vLLM 0.19, Ollama 0.21 — всё с поддержкой в день релиза.
- Jazzband сворачивается. Площадка коллективного мейнтейнинга 84 проектов закрывается до конца 2026 года. Причины — «slopocalypse» (поток AI-сгенерированных PR-ов) и выгорание единственного админа.
Часто задаваемые вопросы
Что значит принятый PEP 772 для рядового разработчика?
В короткой перспективе — почти ничего. Pip, setuptools и PyPI продолжат работать как раньше. В средней — ускорится принятие крупных решений: например, стандарт lockfile-формата или политика для AI-сгенерированных пакетов на PyPI наконец получит формальный орган, который имеет право это решать. Совет начнёт работу после первых выборов; точные сроки выборов в PEP не указаны, но обычно занимают пару месяцев после принятия.
Стоит ли уже мигрировать на 3.14, если откатывают GC?
Стоит — но дождавшись 3.14.5, в которой откат шипится. Если вы уже на 3.14 и заметили рост памяти по сравнению с 3.13, причина почти наверняка в инкрементальном GC. На 3.14.5 поведение вернётся к старому поколенческому сборщику. Откатываться обратно на 3.13 ради этого не нужно — патч-релиз решает проблему.
Поглощение Astral — это конец uv и Ruff как мы их знаем?
Пока — нет. Лицензии остаются открытыми (MIT/Apache-2.0), команда сохранилась, релизы выходят без смены направления. Структурная страховка — возможность форка, если OpenAI развернёт стратегию. Бэкап-план у сообщества есть; по факту первый месяц прошёл без видимых изменений.
Что такое abi3t и нужно ли мне его трогать?
Если вы пишете чистый Python — не нужно. Это касается мейнтейнеров C-расширений (Cryptography, SciPy, Pydantic, любые проекты с собственным C-кодом). abi3t — отдельный вариант стабильного ABI специально для free-threaded билдов: один wheel будет работать на всех минорных версиях Python с GIL-free сборкой. Цена — нельзя обращаться к полям PyObject напрямую, нужна миграция на API из PEP 697 и PEP 793.
Выводы
Апрель 2026 ощутимо сдвинул сразу два слоя Python-экосистемы. Управленческий — у языка появился второй формальный орган, конкретно отвечающий за упаковку, что давно просили десятки участников. Техническая прод-сторона — команда призналась, что инкрементальный GC из 3.14 не проходит проверку реальностью, и откатила его. На фоне этого поглощение Astral смотрится как индустриальный сигнал: ключевая Python-инфраструктура мигрирует в орбиту крупных AI-вендоров, и сообществу остаётся следить, не превратится ли «product+talent» в «talent-only».
Если поддерживаете C-расширение — следите за abi3t и API-миграцией под PEP 697/793. Если деплоите на 3.14 — планируйте обновление до 3.14.5, как только она выйдет. И если вы в принципе следите за Python — стоит разово посмотреть на состав будущего Packaging Council: пять человек впервые получают мандат принимать решения за всех нас.
Источник: Python News — Real Python.
