Rust 的同化进程持续推进，CPython 降低了对 Rust 的技术要求

21CTO导读：CPython 的维护者们已经放弃了将 Rust 作为 Python 参考实现，比如必要依赖项等想法，转而专注于构建一个可选的 Rust API，供内部 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 Provin所指出的那样，强制引入 Rust 引发了一系列问题。并非所有 Python 实现都构建在支持 Rust 的平台上。此外，构建 Rust 本身也需要 Python，这会在构建过程中造成循环依赖。而且，你还得考虑到强制升级总会招致用户普遍的抵触情绪。

因此在5月份，Smith又修改了提案，取消了将 Rust 作为 CPython 的必要依赖项的要求，并将此问题推迟到未来的提案中再讨论。

Smith提出了修改 CPython 的想法以及取而代之的方案，是让开发者可以编写可选的扩展模块。他们可以使用 Rust 来实现这些功能，但如果选择不启用这些功能，那也是不错的。

Python 的创始人 Guido van Rossum也认同这种更简单的方法是可行的，他在提案中评论道：“我们都知道用 Rust 完全重写是行不通的，但首先在不太重要的组件中引入 Rust，然后逐渐让它接管更重要的组件，这听起来像是一个不错的计划。”

“细节是魔鬼”

至此以后，这群核心开发者们一直在努力将 Rust 集成到构建过程中，并设计一个 Rust API，以便可以使用 Rust crate（库）来构建 Python 本身。该 API 计划在 Python 3.16 版本（预计 2027 年 10 月发布）中推出，该版本还将包含 Rust zlib 压缩库作为测试 crate。

Šedovič指出，Python和Rust都需要做出一些调整才能和谐共存。双方的开发者一直在探讨Rust如何更好地满足Python的需求。

Rust 需要提供对 GCC（GNU 编译器集合）的支持，这对于 CPython 支持的众多冷门平台至关重要。此外，这两种语言在构建标准库和动态共享库的方式上也存在差异，需要进行协调。

Python 需要某种跨语言的“清理器”支持，以确保两种语言处理内存分配的方式不同，不会出现不安全的内存状态。幸运的是，目前已经有一些相关的项目正在进行中，例如BorrowSanitizer ，这得益于与 C/C++ 和 Rust 集成时遇到的相同问题。

最复杂的挑战在于如何增强 Rust 的 Drop trait，以便 Python 对象在从内存中释放时能够获取运行时上下文。他表示，这将需要 Rust 工程师们进行大量的头脑风暴。

Python 也将借鉴 Rust 的一些创新之处。

去年11月的原始提案称赞Cargo是一个“优秀的构建系统”。事实上，它承担了Python生态系统中多个独立功能的工作，实现了整个开发生命周期的自动化。Cargo不仅下载依赖项，还编译它们并将它们链接到其他库，并进行测试。而使用Python，你需要单独的项目初始化、构建、测试和发布工具来完成这些任务。

Python 已经开始效仿 Cargo，推出了uv，这是一个统一的打包和项目管理工具（用 Rust 编写）。

未来 Python 还会借鉴 Rust 的哪些创新，值得我们拭目以待。范·罗森甚至开玩笑说，或许应该把 CPython 改名为“CRPython”。