Python 3.15 ещё не вышел, а его главную фичу уже хотят удалить. Почему руководство языка остановило разработку JIT
Руководящий совет Python неожиданно поставил под вопрос будущее экспериментального JIT-компилятора, который должен был стать одной из заметных функций Python 3.15. Новую разработку в основной ветке CPython остановили до появления полноценного PEP, а без одобренного документа код могут удалить через шесть месяцев.
Исправления ошибок и уязвимостей для уже добавленного JIT-кода продолжат принимать. Новые возможности временно заблокированы, пока команда не подготовит официальное предложение по изменению Python и не пройдет обсуждение в сообществе.
Решение выглядит резким, потому что в Python 3.15 уже нельзя добавлять новые функции, а полноценный релиз ожидается в октябре. В заметках к выпуску говорится, что JIT ускоряет CPython на восемь-девять процентов в среднем по набору тестов на x86-64 Linux.
JIT-компилятор пока остается экспериментальной функцией и по умолчанию выключен. Для запуска разработчику нужно вручную задать переменную окружения PYTHON_JIT=1. Такой подход снижает риск для обычных пользователей, но не снимает вопросов к архитектуре проекта и процедуре включения крупных изменений в CPython.
В заявлении руководящего совета фактически говорится, что JIT не должен был попадать в основную ветку без полноценного PEP. Сейчас с проектом связан PEP 744, но документ носит информационный характер и оставляет открытыми важные вопросы.
Среди нерешенных тем совет назвал дальнейшую поддержку JIT, совместимость с существующими возможностями CPython и инструментами разработки, понятные критерии успеха, а также сосуществование встроенного ускорителя со сторонними JIT-компиляторами.
Член руководящего совета Пабло Галиндо Сальгадо написал, что совет не проявил достаточной строгости к процедуре для изменения такого масштаба. Теперь у команды JIT есть шесть месяцев на подготовку и согласование нового PEP. Если документ не появится или не получит одобрения, код удалят из основной ветки репозитория.
Один из ключевых участников проекта Марк Шеннон назвал полную остановку разработки неудобной для команды. По словам разработчика, требование быстро подготовить PEP создает давление, а ускоренный процесс не даст сообществу достаточно времени для обсуждения.
Шеннон отметил, что новый PEP уже планировали подготовить позже в 2026 году, когда преимущество JIT по скорости должно было стать заметнее. Разработчик попросил дать команде еще месяц или два для продолжения работы и предупредил, что мораторий может сбить темп проекта и отпугнуть новых участников.
Продолжать разработку в отдельном ответвлении, по словам Шеннона, тоже сложно. Оптимизации генерируют слишком большие различия в коде, а поддерживать серьезные расхождения с основной веткой CPython трудно.
После заявления совета будущее JIT-компилятора в CPython стало менее определенным. До паузы проект выглядел как часть долгосрочного развития Python, пусть и в экспериментальном виде. Теперь разработчикам нужно не только описать технический план, но и убедить сообщество, что выбранная архитектура подходит для основной реализации языка.
Совет при этом не требует конкурирующих предложений, но допускает другой путь: Python может получить инфраструктуру для нескольких вариантов JIT, а не механизм, жестко связанный с одной стратегией. Такой подход усложнит обсуждение, потому что команде придется спорить не только о текущем коде, но и о будущей архитектуре ускорения CPython.
Еще один член совета, Донхи На, заявил, что экспериментальному JIT нужен официальный PEP, а текущий момент подходит для сравнения разных подходов. Быстро согласовать новый документ будет непросто, если дискуссия уйдет в сторону архитектурных альтернатив.
Сальгадо и член совета Томас Воутерс дали понять, что шестимесячный срок не выглядит абсолютно жестким. Совет готов проявить гибкость, но хочет, чтобы проект прошел нормальную процедуру и получил понятные критерии развития перед дальнейшим продвижением в основной ветке Python.
Пока проект не закрыт, но JIT больше не выглядит гарантированной частью будущего CPython. Команде придется быстро оформить технический план, пройти обсуждение и доказать, что выбранная архитектура подходит не только для эксперимента, но и для основной реализации Python.