Rust может стать обязательным для CPython: опубликован Pre-PEP

В сообществе Python обсуждают радикальное изменение архитектуры — предложение сделать Rust жесткой зависимостью для сборки интерпретатора. Это не просто эксперимент, а план полной интеграции языка в ядро CPython.

Авторы инициативы указывают, что C исторически страдает от утечек памяти и ошибок сегментации. Rust должен закрыть эти уязвимости архитектурно и упростить работу с многопоточностью, что критически важно для грядущего Python без глобальной блокировки GIL.

План миграции и техническая часть

Внедрение расписано по версиям. В Python 3.15 Rust станет опциональным для ускорения отдельных модулей вроде base64. В версии 3.16 сборка будет прерываться при отсутствии компилятора Rust, если пользователь явно не отключит эту проверку специальным флагом. К релизу 3.17 Rust планируют сделать обязательным требованием.

Для связи с C API предлагают использовать инструмент bindgen и системный крейт cpython-sys. От популярной библиотеки PyO3 решили отказаться, чтобы исключить зависимость от версий стороннего проекта. Актуальность перехода подтверждает статистика с саммита 2025 года: около трети новых расширений для Python уже пишутся на Rust.

Проблемы и реакция разработчиков

Главное техническое препятствие заключается в циклической зависимости. Rust требует Python для собственной сборки, поэтому встречное требование усложнит процесс создания дистрибутивов операционных систем.

Среди Core Developers единства нет. Алекс Гейнор поддержал инициативу, но Стив Дауэр из Microsoft выступил против. По его мнению, добавление необязательных модулей в ядро противоречит курсу на облегчение рантайма. Часть команды опасается повторения сценария ядра Linux, где внедрение Rust спровоцировало конфликт между разработчиками разных поколений.

В случае принятия PEP порог входа в разработку CPython заметно вырастет. Системным программистам придется осваивать Rust, а поддержка старых расширений на C со временем станет сложнее.

Русскоязычное сообщество про Python

Друзья! Эту новость подготовила команда Python for Devs — канала, где каждый день выходят самые свежие и полезные материалы о Python и его экосистеме. Подписывайтесь, чтобы ничего не пропустить!

@python_leader
19.11.2025 12:55 UTC
Первоисточник

Комментарии

@Kelbon
19.11.2025 08:32 UTC
+1

предложение сделать Rust жесткой зависимостью для сборки интерпретатора

кто-то потрудился объяснить как создание жесткой зависимости что-то улучшает?) Ну то есть даже код переписывать уже не надо - просто покупаете наш раст делаете жесткой зависимостью

Это очевидная компания, неочевидно только кто её проводит и на какие деньги)

От популярной библиотеки PyO3 решили отказаться, чтобы исключить зависимость от версий стороннего проекта

))) (у раста тоже есть версии и обратной совместимости особо нет)

@Lord_of_Rings
19.11.2025 08:32 UTC
0

Rust требует Python для собственной сборки

Можно пояснительную бригаду?

@ivankudryavtsev
19.11.2025 08:48 UTC
0

смотрите x.py

@Jijiki
19.11.2025 08:55 UTC
+1

С - утечки памяти и сегментации, ассемблер не даёт надёжности )

@Dozer88
19.11.2025 09:22 UTC
+2

Каким образом язык C связан с утечкой памяти? Может невнимательность программистов?

@Kelbon
19.11.2025 09:44 UTC
+4

кстати, раст не решает утечки памяти - официально у них это заявлено. Ну и это логично

@ImagineTables
19.11.2025 09:51 UTC
0

Это не объяснить, это надо самому понять, изучая Rust. Но я попробую.

Если в бочке с водой заткнуть ВСЕ дырки, утечка прекратится. Это кажется мифом, пока закрыта половина дырок или три четверти. Rust просто запрещает все возможные места для ошибок. Строгость компилятора даёт новое качество надёжности. Просто раньше никто не пробовал сделать такой ЯП.

Как язык, при этом, Rust словно специально сделан максимально непонятным. Чего стоит решение назвать смесь union и VARIANT enum'ом. На эту тему даже на снобистском SO, где любое проявление жизни выжигается, висит заплюсованный камент: они даже enum нормально сделать не смогли!!!11

19.11.2025 10:45 UTC
+3

Если в бочке с водой заткнуть ВСЕ дырки

не закрывает раст "все дырки". По утечкам в целом даже не пытается решить проблему, по другим возможным ошибкам - есть баги в языке, громадная дыра в виде ключевого слова unsafe (без которого ничего толком не написать) и т.д. и т.п.

Ключевая проблема в том, что аксиома и идеология у раста такая: "мы запретим иногда валидные вещи, сделаем язык сложнее и неудобнее для разработчиков, зато получим формально отсутствие УБ при таких-то условиях"

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

19.11.2025 15:17 UTC
+1

ключевого слова unsafe (без которого ничего толком не написать)

То, что без unsafe ничего не написать, это неправда. Не надо верить мне на слово, зайдите на ТГ-каналы по Расту и спросите народ, который на нём пишет каждый день. Там вообще жизнь бурлит, всякие рубрики «Крейт недели» и т.п. Я даже сравню в этом отношении растовский unsafe и сишарповский. Он просто не нужен в большинстве случаев.

формально отсутствие УБ при таких-то условиях

Причём тут вообще UB. Сама концепция UB это архитектурная ошибка, я не понимаю, чем вообще думали создатели C/C++, когда добавляли НЕПРЕДСКАЗУЕМОСТЬ результата вместо ошибки компиляции, это же очевидная ересь в промышленной разработке. Такая же, кстати, как плавающая битность типов. И то, что эту ересь не повторяют в более новых языках, это естественно, это так и должно быть. На ошибках учатся. Но, разумеется, всегда найдутся сишники, которые будут до конца биться и за плавающую битность, и за UB. И фиг с ними.

Я говорю вообще не про UB. Тот, кто хоть раз налетал на memory corruption в большом проекте на C/C++, знает, как это больно. (А налетал каждый, кто над большими проектами работал). У тебя есть всё: исходники, документация, тестовые файлы, доступ к пользователям, знание о том, что баг сидит и время от времени крашит программу, и т.д. и т.п. И при этом при всём можно неделями сидеть и искать, где какой-нибудь байт указателя перезаписывается, а тот уже портит память в рандомном месте. (Если повезёт, то испортит ещё один указатель, и навернётся в третьем месте, и тогда уже концов не найдёшь — кстати, все ошибки этого типа в тех проектах, где я участвовал, программисты находили путём чтения мегабайт кода и внезапного озарения. Очень, знаете, круто отвечать заказчику/работодателю на вопрос об ошибках этого типа, что надо подождать озарения, которое может случиться завтра или через год). По сути, чем хорошо писать под ВМ с автоуправлением памятью (C#, Java, JS) — не тем, что там сборщик мусора позволяет не прибираться за собой, а тем, что таких ситуаций просто не может быть. Автоматическая очистка это мелочь по сравнению с контролем безопасности памяти.

Так вот, я бы никогда не поверил, что можно просто компиляцией, без ВМ, без автоуправления памятью добиться такого же результата в плане надёжности. Сохранив при этом скорость нативных приложений. Но Rust меня переубедил.

19.11.2025 16:13 UTC
0

Сама концепция UB это архитектурная ошибка

в расте тоже есть уб. Только в отличие от С++ полного их списка в расте нет

НЕПРЕДСКАЗУЕМОСТЬ результата вместо ошибки компиляции

когда придумаете как сделать там ошибку компиляции - получите нобелевку

19.11.2025 17:38 UTC
0
  1. Не используйте unsafe.

  2. В случае UB в safe-режиме репортуйте баг разработчикам языка/компилятора. Они, насколько я в курсе, заявляют о цели не иметь UB в safe-режиме. Хотя я вот полуркал сейчас, и нашёл рассказ о баге, приводящем к UB, который жил в компиляторе с 2015 года. Даже не знал про такой.

Нобелевку прошу перечислить в ближайший приют для кошек и собак.

19.11.2025 18:14 UTC
0

пока в языке есть unsafe там столько же уб сколько в С++. С чего вы вообще взяли, что падение на "панике" лучше падения при обращении к nullptr? Это просто ложь, весь раст стоит на лжи и рекламируется постоянно первым упоминая про решение проблемы утечек памяти. Каждый раз. При том что он официально даже не пытается решить эту проблему

20.11.2025 15:30 UTC
+3

Я программирую на расте и благодаря этой "лжи" даже не беспокоюсь о сегфолтах. На С теперь смотрю с ужасом, типа люди ходят по минному полю и не парятся.

20.11.2025 15:54 UTC
+2

Я программирую на расте и благодаря этой "лжи" даже не беспокоюсь о сегфолтах.

Любая проблема в unsafe коде раста (а если даже вы лично его не пишете, то в используемых вами разнообразных библиотеках его точно полно, как и в FFI-обертках к внешним библиотекам на других языках) может протечь куда угодно, и вы так же будете "неделями сидеть и искать, где какой-нибудь байт указателя перезаписывается", как афтар каментов выше пишет про C. А если настанет такой момент, когда забивать шуруп молотком "безопасного" раста больше будет нельзя по объективным причинам и вы решите написать более эффективный код, чем тот, что позволяет вам написать тупорылый борроу чекер, то вам придется писать собственный unsafe код, и вот тут вы окажетесь на минном поле в квадрате, потому что, как выше правильно написал другой афтар каментов, никто на самом деле точно не знает, что является или не является UB в unsafe подмножестве раста (в отличие от C где это худо-бедно описано в стандарте - да, кое-где можно придраться к "не совсем очевидным формулировкам", но тем не менее).

21.11.2025 14:00 UTC
+1

Любая проблема в unsafe коде раста (а если даже вы лично его не пишете, то в используемых вами разнообразных библиотеках его точно полно, как и в FFI-обертках к внешним библиотекам на других языках) может протечь куда угодно

То что UB протекает куда угодно - это свойство самого UB, и вызовет точно такие же проблемы в С, С++ и даже в языках со сборщиком мусора, при вызове FFI например.

Весь вопрос в разделении ответственности между авторами библиотек, и теми кто их использует.

Код библиотек c unsafe в любом случае нужно обвешивать тестими, проверять фаззинг, применять санитайзеры и статические анализаторы и т.д. Что в Rust, что в С, С++, прочих языках (при вызове FFI например).

А в прикладном коде мейнтейнер один раз напишет `#![forbid(unsafe_code)]` в main.rs, выставит сам список зависимостей в Cargo.toml, и может быть уверен что никакой джун не напишет прикладной код с UB.

никто на самом деле точно не знает, что является или не является UB в unsafe подмножестве раста

А вы хотите чтобы все варианты UB были описаны на паре страниц текста? Ну поищите такой-же список хотя бы для С например..

Фраза The following list is not exhaustive; it may grow or shrink означает, что никто не будет вести полный (огромный) список UB, по крайней мере пока не будет формальной модели. Кроме того этот список будет постоянно меняться.

Прямо в 3-м абзаце идет ссылка на Rustonomicon, в котором каждый случай расписан подробно. В части языка там описаны безопасные операции, все остальные - потенциальное UB. А в стандартной библиотеке полностью описаны все случаи UB для каждой unsafe функции или типа.

Таким образом ваше утверждение полностью неверно. Писать unsafe код можно, и он будет гарантированно работать как задумывалось.

Для этого нужно:
- не нарушать правила языка, описанные в Rustonomicon. Причем смотреть версию Rustonomicon, соответствующую Edition вашего кода (2015, 2018, 2021, 2024). Довольно похоже на версии С++, не находите?
- не нарушать правила вызова unsafe функций из std и библиотек, см. документацию этих функций.

20.11.2025 20:55 UTC
0

а теперь представье, что есть не только Виндовс, но и другие ОС, и там есть всякие флаги, банально какая-то ОС сама собирает компилятор GCC, теперь представьте, что вроде безопасность и прочее, но тут нам говорят, нет чувак юзай Generic или я падаю(хотя Генерик вроде по дефолту, но может есть тут тоже нюансы какие-то, 1 из нюансов, что если настройка екслюзивная компилятора/ров придётся насколько я знаю пересобирать софт, чтобы использовались эти настройки ) ), а там нам показали, например, что либу переписали на скорость и она тянет за собой компилятор, или наоборот, тянем растап, а там узнаёца, что компилятор на локалке не подходит, одинаковый код на опр сборке компиляторов по разному вроде работает, эта ситуация со всей базой внутри как раз и хочет это обходить, вы представляете какой рантайм там

попробуйте блендер собрать сегодня 4.4.0 там тоже есть пайтон, представляете если еще она кланг запросит, гцц, и пайтон, и в конце как финишная сборки раст еще соберёт, это ради того, чтобы заюзать решение блендер ну и допустим решили его скомпилять, как вам конечный дизайн? )

можно конечно пойти по простому пути, не настраивать ничего и пользоваться бинарником

просто раст как замена на бинарнике окей, как только реч идёт о настройках или зависимостях и не дай бог компиляции, собираться с растом на сколько я понимаю будет всё ) может я ошибаюсь конечно )

та же ситуация и с явой, и она поставляется бинарником, мы же не собираем все зависимости или собираем?)

тоесть может оказаться так, что производительность не первична ради поддержки на ОС или оборудовании, а это значит если нету бинарника с нужными настройками, придётся что-то делать если это не учтено, этим и красив С поидее

20.11.2025 23:36 UTC
0

the_hidden_cost_of_software_libraries_c_vs_rust тут еще есть что-то интересное со сравнениями

28.11.2025 12:18 UTC
+1

концепция UB это архитектурная ошибка

это возможность для оптимизаций

28.11.2025 15:31 UTC
-1

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

29.11.2025 06:43 UTC
0

стебешься что-ли?

ты точно доктор?

C++ язык для предельных оптимизаций где требования к скорости очень высоки

@Jijiki
19.11.2025 10:09 UTC
0

фрагментация даже в расте произойдёт ) самое интересное, нету магии к сожалению, просто раст предлагает аля готовое решение на этапе компиляции ), далее же это для того чтобы положиться на Раст, на его механизм и тут будут теже проблемы как и всегда, перезапись/пересоздание и прочее, что иногда и не только на С/С++ приводит к фрагментации ), тоесть создать убирание утечек, надо было еще оптимизиатор по работе с памятью сделать и выводить на этапе компиляции вы неправильно работаете с памятью тут и тут, надо вот так, почитать можно тут, а так получается проект не собирается потомучто, там посчитались ссылки..., что-то проанализировалось, как бы собираешь, а логические ошибки не аналазируются полностью, и в итоге фрагментация может произойти всё равно, а если оно так, то синтаксис надо стандартизировать, чтобы читать и исправлять было удобно