CPython решил проверить Rust не приказом, а экспериментом. Команда Rust for CPython выбрала путь, при котором новый язык сможет войти в проект без обязательной перестройки всей цепочки сборки. Компоненты стандартной библиотеки предлагают писать на Rust, но оставлять необязательными, чтобы отсутствие нового компилятора не мешало собрать интерпретатор на поддерживаемых и редких платформах.
Изначальная идея была жёстче. В ноябре 2025 года авторы pre-PEP допускали, что Rust со временем станет обязательной зависимостью CPython и сможет использоваться во всём коде. После обсуждения предложение быстро сузили до необязательных модулей расширения, а обязательный Rust вынесли в возможный будущий PEP, который сообществу придётся обсуждать отдельно.
Такой порядок снимает сразу несколько спорных вопросов. CPython работает не только на массовых x86-64 и Arm-системах, а Rust доступен не везде одинаково. Кроме того, собственная сборка Rust использует Python, поэтому обязательная зависимость создала бы циклическую схему: для нового Python понадобился бы Rust, а для сборки Rust уже требовался бы Python.
Техническая мотивация при этом никуда не исчезла. Значительная часть CPython написана на C, где ошибки управления памятью способны приводить к выходу за границы буфера, обращению к уже освобождённым объектам и гонкам данных. Rust блокирует многие такие ошибки ещё при компиляции, хотя участки unsafe и граница между Rust и C всё равно потребуют отдельного контроля.
Постепенное внедрение уже стало общей стратегией крупных системных проектов. В Linux поддержка Rust прошла путь от эксперимента до стабильного инструмента, и в апреле 2026 года язык перестал считаться экспериментальным для ядра. CPython, однако, не повторяет модель ядра напрямую и пока не требует от сопровождающих работать с двумя языками одновременно.
Проект Rust for CPython уже собрал отдельную ветку интерпретатора с поддержкой Cargo и экспериментирует с внутренним Rust API. Первая задача такого интерфейса заключается не в публичной библиотеке для сторонних разработчиков, а в безопасной связи нового кода с внутренними структурами CPython. Публичную стабилизацию API планируют обсуждать позже отдельным предложением.
Одним из испытательных проектов стал zlib-py, небольшой модуль, который подключает реализацию zlib-rs к Python. Тесты самого проекта показывают заметное ускорение ряда операций сжатия и распаковки, хотя отдельные сценарии, включая CRC32 на ARM64, могут работать медленнее. Такой прототип нужен прежде всего для проверки сборки, интерфейсов и поведения Rust рядом с C.
Работа рассчитана на Python 3.16. В апрельском плане команда нацелила первый код на Rust именно на эту ветку, финальный релиз которой ожидается 5 октября 2027 года. До этого проекту предстоит решить вопросы линковки, совместной проверки памяти в C и Rust и корректного освобождения Python-объектов с учётом состояния самого интерпретатора в разных средах.
Отдельная сложность связана с инструментами сборки. Cargo удобно управляет зависимостями и компиляцией, но CPython десятилетиями строит переносимый процесс вокруг C-компиляторов и собственных сценариев. Команды Rust и Python обсуждают поддержку GCC, совместимость библиотек и способы не заставлять дистрибутивы менять привычные цепочки только ради необязательного компонента.
В результате речь пока не идёт о переписывании Python на Rust. Даже Гвидо ван Россум поддержал постепенный подход, при котором новый язык сначала появляется в менее критичных частях. Для Rust такой путь уже доказал жизнеспособность в других крупных кодовых базах, где безопасность памяти стала главным аргументом за точечную миграцию вместо тотальной замены старого кода.
Главный итог нынешней стратегии состоит в разделении технического эксперимента и обязательного требования. Разработчики CPython получают возможность проверить Rust на реальном коде, а сборщики дистрибутивов и владельцы необычных платформ не обязаны менять окружение заранее. Вопрос о превращении Rust в обязательную часть CPython остаётся открытым и потребует отдельного решения после испытаний.