CPython的维护者已放弃将Rust作为Python参考实现的必需依赖项，转而专注于一项侵入性较小的任务：构建一个可选的Rust I用于Python内部开发。Rust项目经理Tomáš Šedovič在上周于蒙特利尔举行的RustConf上解释说，此举“回避了人们提出的许多担忧”。Šedovič及其他Rust相关人员一直在与CPython核心开发者合作，以简化两种环境之间的集成。CPython修订后的方案避开了在Python中更激进地推广使用Rust的做法，而这种方式曾在去年搅动了Linux内核社区对Rust的采用。

美味佳肴仍遭不愿品尝的味蕾拒绝。去年11月，Python程序员Emma Smith提出了将Rust支持融入Python的想法，最初是为了编写扩展模块，但总体计划是让Rust成为CPython的必需依赖项，以便在整个CPython代码库中使用。这类似于Rust与C编程语言之间的关系，CPython很大程度上是建立在C语言之上的（因此得名）。在内存方面，C语言带来了一定的安全风险，因为内存需要在代码中手动分配和释放。而内存安全的Rust在编译时就能消除这一整类错误，因此引起了CPython开发者的兴趣。然而，正如同行Liam Proven当时指出的那样，强制包含Rust引发了一系列问题。

并非所有 Python 实现都构建在支持 Rust 的平台上。此外，构建 Rust 本身需要 Python，这会在构建过程中造成循环依赖。而且你还得考虑，任何强制升级都会招来那种常见的、爱抱怨的抵触情绪。因此，史密斯在 5 月修改了提案，放弃了将 Rust 设为 CPython 必需依赖的强制要求，把它推迟到未来的提案中。相反，史密斯提出了修改 CPython 的想法，让开发者能够编写可选的扩展就连Python的创造者吉多·范罗苏姆也赞同这一更为简便的方法，他在评论中表示：“我们都知道，完全用Rust重写是行不通的，但一开始先在不太重要的组件中引入Rust，然后逐渐让它接管更关键的组件，这听起来是个不错的计划。”细节决定成败。自那以后，将Rust融入构建过程的工作一直在继续，并设计了一个Rust I，使得Rust crate（即库）能够用于构建Python本身。该I计划在2027年10月发布的Python 3.16版本中推出，届时还将包含Rust zlib压缩库作为测试crate。Šedovič指出，Python和Rust双方都需要做出一些调整，才能和谐共处。双方阵营的开发者一直在讨论Rust如何更好地兼顾Python的关切。

从Rust中需要的一项支持是对GCC的支持，这对于CPython所支持的众多冷门平台而言是必需的。这两种语言在构建标准库和单个动态共享库的方式上也存在差异，必须加以协调。Python将需要某种跨语言的“消毒器”支持，以确保两种语言处理内存分配的方式之间不会出现不安全的内存状态。幸运的是，在这方面已经有若干努力正在进行，例如BorrowSanitizer，这得益于同样困扰C/C++与Rust集成的问题。最复杂的挑战将是扩展Rust的Drop trait，以便Python对象在从内存中释放时能够接收运行时上下文。他说，这一项将需要Rust工程师们进行大量深入思考。Python也可能从Rust中借鉴一些创新。

去年11月的最初提案称赞 Cargo 是“出色的构建系统”。事实上，它承担了 Python 领域中若干独立功能的职责，将整个开发生命周期自动化。Cargo 不仅能下载依赖项，还能编译它们并将其与其他库链接，并对它们进行测试。而在 Python 中，要完成同样的任务，你需要分别使用项目初始化、构建、测试和发布工具。Python 已经通过 uv（一个用 Rust 编写的统一打包与项目管理器）在这方面追随 Cargo 的步伐。看看 Python 未来还会从 Rust 借鉴哪些其他创新，将会很有意思。Van Rossum 甚至开玩笑说，也许 CPython 可能需要改名为“CRPython”。®