Python 正式向 Rust 招手：CPython 准备告别纯 C 时代，连 pip install 都可能因此变快？

本文永久链接 – https://tonybai.com/2026/10/07/python-cpython-rust-integration

大家好，我是Tony Bai。

【导读】

Python 社区正在酝酿一场可能改变其底层技术版图的变革。

在 2026 年 Python Language Summit 上，一个颇具分量的话题再次被摆上台面：CPython 是否应该引入 Rust？

这不是某个开发者的个人尝试，也不是又一个用 Rust 重写 Python 的民间项目，而是一个由 Python 核心开发者参与推动、正在寻求正式进入 CPython 开发流程的项目——Rust for CPython。

他们甚至已经选好了第一个试验田：zlib 模块。

如果计划顺利，Python 3.16 就可能首次携带 Rust 实现，而且几乎每一次 pip install 都有机会从中受益。

但真正值得关注的，并不只是性能提升。

过去，Python 的底层世界几乎完全由 C 语言构建。如今，随着 JIT、Free-threading 等复杂特性的持续演进，CPython 面临着越来越严峻的内存安全和工程维护挑战。Rust 的出现，正在为这个拥有三十多年历史的项目打开一扇新的大门。

Python 为什么需要 Rust？Rust 又需要为 CPython 做些什么？这场跨越两种语言的技术融合，将如何改变 Python 的未来？

本文结合 Python Language Summit 2026 的官方讨论，深入拆解 Rust for CPython 项目的技术动机、实施路线、首个落地模块，以及 Python 核心团队提出的几道关键门槛。

文章要点

C 语言的工程压力正在增加。 CPython 的 type-crash 问题持续增长，2025 年相关问题达到 222 个，2026 年的趋势预测更高。
Rust 不只是性能工具，更是内存安全工具。 Python 团队希望借助 Rust 减少一类长期困扰 C 语言项目的内存安全问题。
首个试验田已经选定：zlib。项目计划使用经过充分测试的 zlib-rs，为 Python 的 zlib 模块提供可选 Rust 后端。
Python 3.16 可能迎来第一个 Rust 模块。初期保留 C 实现作为回退，Rust 不是强制依赖。
这不是一次大规模重写。 CPython 将在相当长一段时间内成为 C 与 Rust 并存的双语言项目。
Rust API 需要重新设计。项目希望采用符合 Rust 惯用方式的接口，包括所有权管理、RAII 和 Result 错误处理。
真正的挑战不仅是技术。平台兼容性、核心开发者接受程度、构建系统、第三方依赖管理，都会决定 Rust 能否成为 CPython 的正式组成部分。

Python 社区可能要迎来一次重要的底层技术变革了。

2026 年 9 月 30 日，Python 官方博客发布了一篇来自 Python Language Summit 2026 的会议纪要，标题相当直接：

《Rust for CPython》——让 Rust 进入 CPython。

这篇文章透露了一个值得整个 Python 和 Rust 社区关注的信号：Python 核心开发团队已经不再只是讨论 Rust 是否值得引入，而是开始认真规划它如何进入 CPython 的正式开发与构建流程。

这项工作由 Rust for CPython 项目团队推动。David Hewitt 作为项目代表，在本届 Python Language Summit 上汇报了最新进展，并向 Python 核心开发者提出了一系列问题：

Rust 应该从 CPython 的哪些部分开始？
如何设计 C 与 Rust 之间的接口？
如何处理不同操作系统和硬件架构的兼容性？
如何让现有 Python 核心开发者接受 Rust？
最重要的是：Rust 需要达到什么标准，才能成为 CPython 的正式组成部分？

值得注意的是，这并不是一次试图用 Rust 重写 Python 的激进运动。

项目已经选定了第一个目标：zlib 模块。

按照目前提出的路线图，Python 3.16 就可能首次引入可选的 Rust 实现，而到了更远的未来，Rust 甚至可能成为构建 CPython 的必要工具链之一。

为什么 Python 突然需要 Rust？

这背后，隐藏着一个 C 语言项目正在面对的工程困境。

Python 为什么需要 Rust？C 语言的舒适区正在变成危险区

要理解 Rust 为什么会进入 CPython，我们首先需要看看 Python 当前所面临的工程挑战。

很多人可能不知道，我们日常使用的 Python，其主流解释器 CPython，底层绝大部分都是用 C 语言实现的。

从对象模型、内存管理，到解释器执行循环、垃圾回收，再到各种标准库模块，C 语言构成了 CPython 的技术基石。

这套架构已经支撑 Python 走过了三十多年。

但问题也随之而来。

C 语言给予开发者极大的自由，同时也将大量内存安全责任交给了开发者。

指针是否有效？内存是否已经释放？缓冲区是否越界？多个线程是否会同时访问同一块内存？

这些问题如果处理不当，就可能导致程序崩溃、内存破坏，甚至安全漏洞。

对于一个需要长期维护、支持众多平台、拥有庞大第三方生态的解释器项目来说，这种风险并不会随着代码规模增长而消失，反而可能越来越难以控制。

而最近几年，CPython 正在进行一系列重要的底层技术改造。

例如：

新的解析器和解释器架构演进；
JIT 编译器的引入；
Free-threading，即自由线程模式的推进。

这些工作都在不断增加 CPython 的底层复杂度。

尤其是 Free-threading，它试图让 Python 在不依赖传统全局解释器锁（GIL）的情况下实现真正的多线程并行执行。

这意味着，过去某些依赖 GIL 隐式保护的代码，现在必须更加谨慎地处理并发访问和对象生命周期。

复杂度上升，意味着潜在错误也会增加。

一个值得警惕的数据：type-crash 持续增长

David Hewitt 在演讲中展示了一组数据：CPython GitHub 仓库中被标记为 type-crash 的问题数量。

这类问题与解释器崩溃有关，是观察底层稳定性挑战的一个重要指标。

官方演讲展示的数据如下：

这组数据不意味着所有崩溃都来自内存安全问题，也不能简单地将其全部归因于 C 语言。

但它至少反映出一个现实：随着 CPython 引入更多复杂的底层特性，维护解释器的难度正在增加。

David 提到了 Android 团队采用 Rust 的经验。

Android 团队曾用一句话总结 Rust 带来的变化：Move fast and fix things。

更值得注意的是，他们观察到：在完成相同规模的补丁时，Rust 项目需要的代码修订轮次更少。

这背后的价值，不仅仅是减少 Bug。

它意味着开发者可以将更多精力投入功能设计，而不是反复排查那些本可以通过类型系统和所有权机制提前避免的错误。

这正是 Rust 对 CPython 最有吸引力的地方。

Rust 能解决什么，又不能解决什么？

Rust 最大的优势之一，是通过所有权（Ownership）、借用（Borrowing）和生命周期（Lifetime）机制，在编译阶段约束内存访问行为。

例如，在 C 语言中，开发者可能需要手动管理一个缓冲区的分配和释放：

char *buf = malloc(size);

if (buf == NULL) {
    return NULL;
}

/* 使用 buf */

free(buf);

一旦出现提前返回、异常分支遗漏或者重复释放，就可能引发内存问题。

Rust 则可以通过 RAII 和所有权机制，将资源释放与作用域绑定：

Rust

{
    let buf = vec![0u8; size];

    // 使用 buf
}

// 离开作用域，buf 自动释放

这不是说 Rust 可以自动消除所有 Bug，而是它能够将一部分原本依赖开发者自觉遵守的规则，转变为编译器强制执行的约束。

不过，David 也特别强调：

使用 Rust 并不意味着代码天然没有 Bug，更不意味着安全问题从此消失。

逻辑错误、算法错误、并发设计问题依然可能存在。

因此，Rust for CPython 团队还计划结合以下工程实践：

Property-based Testing：基于属性的测试；
Fuzzing：模糊测试；
严格的代码审查与工程质量控制。

Rust 提供的是更可靠的安全基础，而不是免于测试的通行证。

不是重写 Python，而是让 C 和 Rust 协同工作

看到这里，可能有人会产生一个疑问：

既然 Rust 在内存安全方面具有优势，为什么不直接用 Rust 重写整个 CPython？

事实上，这个问题在会议上也被提出了。

Larry Hastings 就询问了为什么该项目不是一次完整的重写，甚至建议项目团队考虑将成功展示为一个独立分支。

David 的回答很明确：

CPython 不应该为了使用 Rust 而使用 Rust。

这是整个项目非常重要的设计原则。

CPython 已经拥有超过百万行规模的 C 代码，以及成熟的开发流程、平台支持体系和庞大的生态。

一次性重写，不仅工作量巨大，还会带来难以接受的兼容性、性能和维护风险。

更重要的是，Rust 并不是所有底层代码的最佳选择。

某些代码可能已经足够成熟，性能也非常优秀，没有必要仅仅因为 Rust 更现代就将其重写。

因此，Rust for CPython 采取的是渐进式集成策略。

它希望从小模块开始，逐步建立 Rust 与 CPython 之间的协作机制。

这也意味着，在相当长的一段时间里，CPython 可能都将是一个 C 与 Rust 并存的双语言项目。

Rust for CPython 的演进路线

根据 David 在会议上展示的规划，整个项目大致分为几个阶段：

这条路线有几个值得特别关注的节点。

第一阶段：2026 年，打好基础。

项目需要先完成 Rust 构建系统、CI 集成，以及 Rust API 的概念验证。

同时，团队计划在 2026 年底通过 PEP 明确项目的成功标准。

这一步非常关键。

因为对于 CPython 这样的基础设施项目来说，引入一种新的实现语言，绝不是增加几个源文件那么简单。

它意味着构建系统、测试体系、发布流程、维护者技能结构都可能发生变化。

第二阶段：Python 3.16，首次交付 Rust 代码。

按照目前的提议，Python 3.16（预计 2027 年 10 月发布）将引入第一个可选 Rust 后端。

这里有一个非常重要的设计：

Rust 实现是可选的，原有 C 实现继续保留，作为回退方案。

这意味着，即使某个平台暂时无法使用 Rust，或者构建环境不满足要求，CPython 仍然可以使用传统 C 实现。

这是一种典型的渐进式工程策略。

先让 Rust 在真实环境中接受检验，再决定是否扩大使用范围。

第三阶段：Python 3.17，扩大应用范围。

到了 Python 3.17（预计 2028 年 10 月），项目希望进一步解决平台兼容性问题，并探索在更多模块中使用 Rust。

官方演讲提及了以下潜在方向：

io
json
xml
memoryview
parser

注意，这些都是潜在的后续探索方向，并不意味着它们已经确定会在 Python 3.17 全部完成 Rust 迁移。

第四阶段：2029 年以后，Rust 可能成为 CPython 的必需组成部分。

这是路线图中最具标志性的阶段。

项目希望在未来某个版本中，让 Rust 成为构建 CPython 的必要工具链之一，并提供公开的 Rust API。

不过，这并不是一个已经确定的发布时间承诺。

最终是否能够走到这一步，取决于前面几个阶段能否达到预先制定的成功标准。

换句话说，Rust 能否进入 CPython 的核心体系，最终需要用实际工程结果说话。

为什么第一个目标是 zlib？答案可能让你每天都在受益

如果要在 CPython 中挑选一个模块作为 Rust 集成的试验田，你会选择什么？

Rust for CPython 团队选择了 zlib。

这个决定其实相当有意思。

首先，zlib 是一个功能明确、边界相对清晰的模块。

它负责压缩与解压缩，是 Python 标准库的重要组成部分。

相比解释器核心、对象系统或者垃圾回收器，zlib 的功能范围更容易控制。

这非常适合用来验证 Rust 与 CPython 的集成方案。

但还有一个更加重要的原因：

zlib 模块可以帮助团队验证外部 Rust Cargo 依赖如何进入 CPython 的构建体系。

Rust 生态的一个重要特点，就是 Cargo 包管理体系。

开发者可以通过 Cargo.toml 声明依赖，再由 Cargo 负责下载、编译和管理依赖关系。

但对于 CPython 来说，这件事远没有那么简单。

Python 的构建系统有自己的历史和约束，官方发布还需要照顾数量众多的平台和发行渠道。

如何将 Cargo 依赖纳入现有体系，同时不破坏原有的构建与分发流程，是项目必须解决的问题。

而 zlib 恰好提供了一个合适的切入点。

zlib-rs：一个已经经过实战检验的 Rust 实现

Rust for CPython 团队计划使用 zlib-rs 作为底层实现。

项目参考：zlib-rs，Rust 语言实现的 zlib 兼容压缩库。

它并不是一个刚刚诞生的实验性项目。

David 在演讲中介绍，zlib-rs 已经经过大量测试，并被 Firefox、uv 和 Cargo 等项目使用。

此外，团队还提到，zlib-rs 在许多平台上的性能优于传统 zlib 和 zlib-ng。

这里值得注意的是，性能优势是项目团队引用的已有测试结果，并不代表所有平台、所有输入数据和所有工作负载下都一定更快。

但这至少意味着，CPython 不必从零开始编写一个 Rust 压缩算法。

它可以借助已有的成熟实现，重点解决 Rust 与 Python 之间的集成问题。

而一旦这个方案成功，受益者可能远不止直接调用 zlib 模块的开发者。

每一次 pip install 都可能变快？

这里出现了一个非常有意思的推论。

Python 的包管理和分发体系大量使用压缩技术。

无论是下载、解压缩 Python 包，还是处理各种归档文件，压缩与解压缩都是经常发生的操作。

如果 CPython 能够采用性能更好的 zlib Rust 实现，那么这些操作就有机会获得性能收益。

David 在演讲中甚至提到：如果这一方案成功，Python 3.16 中几乎每一次 pip install 都可能因此加速。

当然，这句话需要正确理解。

并不是所有 pip install 都会受到相同程度的影响。具体收益还取决于包的分发格式、安装过程中的解压缩工作量，以及其他性能瓶颈。

但它揭示了一个很有意思的事实：

Rust 并不一定要进入 Python 的核心执行循环，才能让整个 Python 生态受益。

有时，只需要优化一个足够基础、足够高频的底层模块，就可能产生广泛影响。

Rust API 怎么设计？不能只是给 C API 套一层 Rust 语法

如果说 zlib 是 Rust for CPython 的第一个试验田，那么 Rust API 就是决定这个项目能否长期发展的关键基础设施。

这是因为，Rust 与 C 在内存管理和错误处理方面有着完全不同的设计哲学。

如果只是简单地将 C API 包装成 Rust 函数，那么开发者依然需要面对大量不符合 Rust 语言习惯的接口。

这样不仅无法充分发挥 Rust 的优势，还可能让代码变得更加复杂。

David 在演讲中展示了一段假想的 Rust API 代码。

这段代码模拟了 Python 的 zlib.decompress 函数：

#[pyfunction(signature = (
    data,
    /,
    wbits=MAX_WBITS,
    bufsize=DEF_BUF_SIZE,
))]
fn decompress(
    py: Python<'_>,
    data: Py<PyObject>,
    wbits: c_int,
    bufsize: isize
) -> PyResult<Py<PyBytes>, PyErrRaised> {

    // buf will be cleaned on scope exit
    let buf = PyObject::get_buffer(py, &data)?;
    let decoded = /* ... */;

    Ok(PyBytes::new(py, &decoded))
}

这段代码虽然只是 API 设计草图，却透露了几个非常重要的设计方向。

1. 使用属性宏，减少样板代码

#[pyfunction(signature = (...))]

这里使用了 Rust 的属性宏。

它的设计思路与 Python 生态中的 Argument Clinic 有些类似。

Argument Clinic 是 CPython 用来根据 Python 风格的函数声明，自动生成 C 参数处理代码的开发工具。

而在 Rust API 中，项目希望通过属性宏表达函数签名，再由工具生成必要的绑定代码。

这样，开发者就不需要手动处理大量重复的参数解析逻辑。

2. 显式传递 Python 解释器上下文

py: Python<'_>

这是一个非常值得关注的设计。

Python 的对象操作离不开解释器上下文。

随着 CPython 推进 Free-threading，以及多解释器支持的持续发展，过去一些隐含依赖全局状态的设计需要重新审视。

通过显式传递 Python<'_>，Rust API 可以让解释器上下文成为函数调用的一部分。

这有助于更清晰地表达哪些操作需要访问 Python 运行时。

它也为未来处理不同解释器实例之间的状态隔离提供了基础。

3. 使用智能指针管理 Python 对象

data: Py<PyObject>

这里使用了 Py<T> 这样的智能指针抽象。

Python 对象的生命周期管理与普通 Rust 对象并不完全相同。

Python 有自己的引用计数、垃圾回收和对象管理机制。

因此，Rust 不能简单地将 Python 对象当成普通的 Rust 值处理。

通过专门的智能指针类型，API 可以将 Python 对象的生命周期管理规则封装起来，降低开发者直接操作底层指针的风险。

4. 使用 Result 表达错误

) -> PyResult<Py<PyBytes>, PyErrRaised>

Rust 的错误处理机制同样被引入其中。

函数返回的不是一个简单的指针，而是一个结果类型。

成功时返回 Python 字节对象，失败时返回错误。

再结合：

let buf = PyObject::get_buffer(py, &data)?;

这里的 ? 操作符可以自动传播错误。

这意味着 Rust 开发者可以按照 Rust 惯用的方式处理错误，而不需要在每一个函数中重复编写 C 风格的错误检查逻辑。

5. RAII：离开作用域，自动释放资源

代码注释中的这句话尤其值得注意：

// buf will be cleaned on scope exit

在 C API 中，开发者通常需要显式管理资源的申请和释放。

而 Rust 可以利用 RAII，将资源生命周期与作用域绑定。

当函数提前返回，或者通过 ? 传播错误时，已经创建的局部资源依然能够按照 Rust 的析构规则自动清理。

这正是 Rust 在大型系统项目中非常有价值的一项能力。

不过，需要强调的是，这段代码是会议上展示的 API 设计示意，并不是已经发布、可以直接使用的稳定公共 API。

它的真正意义在于：

Rust for CPython 并不打算让 Rust 开发者用 C 的方式写 Rust，而是希望设计一套能够发挥 Rust 语言优势的接口。

Python 核心开发者并不都想学习 Rust，这才是最大的现实挑战

如果只从技术角度看，Rust for CPython 的方向似乎相当合理。

Rust 有内存安全优势，Cargo 有成熟的依赖管理体系，zlib-rs 也已经有实际应用。

但一个拥有三十多年历史的项目，真正的挑战往往不在代码本身，而在人。

Python 核心开发团队并不是一个所有人都熟悉 Rust 的团队。

有人精通 C，有人熟悉 Python 内部机制，也有人长期维护某些特定平台和模块。

要求所有核心开发者都掌握 Rust，显然不现实。

在会议讨论中，Larry Hastings 就明确表达了自己的顾虑：

他并不特别期待为了参与 CPython 开发而去学习 Rust。

David 对此给出了一个比较务实的回答：

CPython 有很多地方根本不需要使用 Rust。

这也是为什么项目选择从小模块开始，而不是全面迁移。

开发者可以继续在熟悉的 C 代码中工作，只有在真正需要使用 Rust 的模块中，才需要理解相关接口。

不过，David 同时也提醒大家：

声称 Rust 将永远只是一个可选项，并不诚实。

因为项目长期目标中，确实包含让 Rust 成为 CPython 构建过程必要组成部分的计划。

换句话说，Python 核心开发者最终可能需要逐渐适应一个 C 与 Rust 共存的开发环境。

一个非常有意思的争论：Rust API 要不要照顾 C 开发者？

会议中还出现了一个值得关注的技术讨论。

Thomas Wouters 提出了一个观点：

设计 Rust API 时，不应该为了照顾那些习惯 C API 的开发者，而牺牲 Rust 自身的设计优势。

他甚至用了一句颇为幽默的话：

“不要为了恐龙们做妥协。”

当然，他也把自己算在了这些“恐龙”之中。

这实际上触及了一个非常重要的工程设计问题：

当一种新语言进入一个成熟项目时，究竟应该迁就旧世界，还是建立新世界的规则？

如果 Rust API 完全按照 C API 的思路设计，那么 Rust 的类型系统、所有权机制和错误处理优势就可能无法充分发挥。

但如果完全按照 Rust 的惯用设计来构建接口，又可能增加现有核心开发者的学习成本。

David 的态度相对平衡。

有些地方应该充分利用 Rust 的特性，例如作用域退出时自动释放资源。

但也有一些非常 Rust 惯用的设计，未必适合 CPython 的实际需求。

因此，API 设计需要在 Rust 的语言优势与 CPython 开发者的实际使用体验之间寻找平衡。

这不是一个简单的技术问题，而是一个长期的社区协作问题。

比 Rust 语法更棘手的，是平台和依赖管理

除了开发者接受程度，Python 核心团队还提出了两个非常现实的问题。

它们可能比设计 Rust API 本身更加棘手。

问题一：Rust 能覆盖 CPython 支持的所有平台吗？

CPython 是一个高度重视平台兼容性的项目。

官方支持众多操作系统、硬件架构和平台组合。

在会议中，David 提到，CPython 当时在 Tier 1、Tier 2 和 Tier 3 等级中正式支持的架构与平台组合约有 20 种。

相比之下，Rust 在某些平台上的支持程度曾经不够理想。

这也是此前社区对 Rust 集成存在顾虑的重要原因。

不过，David 表示，Rust 的平台支持能力相比上一年已经有了明显改善，这个问题正在逐渐变得不那么突出。

项目计划让 Python 发行商在 Python 3.16 阶段尝试可选的 Rust 支持，并将平台相关问题及时反馈给上游。

希望能够在 Python 3.17 的时间窗口内解决主要兼容性问题。

这里有一个非常重要的原则：

不能因为 Rust 在主流 Linux、Windows 和 macOS 上运行良好，就认为它已经适合进入 CPython。

CPython 必须考虑更广泛的用户和发行渠道。

Rust 集成只有在这些平台上都能可靠构建和运行，才有可能成为正式的基础设施。

问题二：Cargo 依赖会不会成为新的维护噩梦？

这是会议上另一个非常尖锐的问题。

Pablo Galindo Salgado 对引入 Cargo 外部依赖表达了明显的担忧。

CPython 对第三方依赖的管理一直非常谨慎。

其中一个原因是安全维护。

如果 CPython 引入了更多第三方库，那么每当这些依赖出现安全漏洞，Python 发布团队可能就需要：

确认受影响的依赖版本；
评估漏洞对 CPython 的影响；
更新依赖；
重新构建和发布 Python；
确保各平台发行版本保持一致。

这会增加维护负担。

而 Cargo 的依赖生态恰恰非常丰富。

如果不能控制依赖数量，Rust 的引入可能会让 CPython 的供应链管理变得更加复杂。

Pablo 甚至将其称为可能阻碍整个项目的重大问题。

David 的回应是：尽可能减少外部依赖。

以当前选择的 zlib-rs 为例，团队希望将其作为一个独立依赖引入，而不是带入一大批额外的第三方库。

此外，项目还提出了一个重要的构建策略：

将 Rust 依赖的源代码进行 Vendor 化管理。

也就是说，CPython 构建时不应该依赖网络下载 Cargo 包。

这意味着：

即使构建 CPython 的机器没有网络，也不应该因为 Cargo 无法访问外部仓库而导致构建失败。

David 还提到，Cargo 本身拥有相对完善的依赖 Vendor 机制，Rust for CPython 的概念验证已经在使用这套机制。

与此同时，Rust 依赖源码不会直接放在 CPython 主仓库中，而是考虑通过现有的 cpython-source-deps 仓库体系进行管理。

这也是一个非常值得关注的工程细节。

它表明，Rust for CPython 不只是希望解决语言之间的互操作问题，还在认真考虑如何适配一个大型开源项目长期以来形成的供应链管理规则。

Rust 要通过什么考核，才能真正成为 CPython 的一部分？

讨论到最后，David 提出了一个非常关键的问题：

Rust for CPython 项目需要达到什么标准，才能进入下一阶段？

这其实是整个项目能否成功的核心。

回顾 CPython 过去的重大技术改造，例如 JIT 和 Free-threading，Python 团队都曾经明确提出过相应的成功标准。

新技术不能仅仅因为看起来先进，就被允许增加项目的复杂度。

Rust 也不例外。

David 在会议上提出了三个主要考核方向。

考核维度	核心要求
社区接受度	大多数活跃的 Python 核心开发者愿意使用 Rust API 实现功能
性能	不应对 CPython 性能基准测试造成有意义的负面影响
平台兼容性	Rust 必须支持所有 CPython 分级支持的平台，发行商的构建体验也应当是可接受的

这里有一个非常值得注意的细节。

David 特意强调，第一项要求使用的是：

Open，而不是 Familiar。

也就是说，Python 团队并不要求所有核心开发者在项目正式推进之前就已经熟悉 Rust。

他们更关注的是：这些开发者是否愿意接受 Rust API，并愿意在合适的场景下使用它。

这其实是一个非常聪明的策略。

对于一个成熟的开源项目来说，要求所有人立刻掌握一项新技术，几乎不可能。

但让大家先理解它的价值，并愿意尝试，已经是非常重要的一步。

David 还表示，项目团队计划通过调查问卷等方式，了解核心开发者在参与 CPython 开发过程中使用 Rust 的实际情况，再决定是否推动项目进入下一阶段。

这说明，Rust for CPython 并不是一个只关注技术指标的项目。

它需要同时证明三件事：

Rust 确实能带来工程价值；
Rust 不会破坏现有平台和性能；
CPython 社区愿意长期维护一个 C 与 Rust 并存的代码库。

只有这三个条件同时成立，Rust 才可能真正成为 CPython 的一部分。

Python 与 Rust 的结合，意味着什么？

如果把这次 Python Language Summit 的讨论放在更大的技术背景下看，就会发现一个有意思的趋势。

过去十多年，Python 凭借简单的语法、丰富的生态和较低的学习门槛，成为人工智能、数据科学、自动化和 Web 开发领域的重要基础语言。

但 Python 的优势主要体现在应用层。

在底层系统、性能敏感模块和运行时基础设施领域，C 语言一直承担着核心职责。

如今，这种格局正在发生变化。

Rust 正在逐步进入越来越多成熟系统项目。

Linux 内核开始接纳 Rust，Android 将 Rust 用于系统组件，Firefox 也长期使用 Rust 构建关键基础设施。

现在，轮到 CPython 认真考虑这件事了。

这并不意味着 C 语言正在退出历史舞台。

恰恰相反，C 依然拥有无可替代的生态基础、成熟的工具链和大量经过多年验证的代码。

但随着软件系统越来越复杂，单纯依靠开发者经验和代码审查来保证内存安全，已经变得越来越困难。

Rust 提供了一种新的可能：

让编译器承担一部分过去必须由开发者手动保证的安全责任。

对 Python 来说，这可能带来三个层面的长期收益。

首先，是底层工程安全性的提升。

通过 Rust 的类型系统和所有权机制，降低缓冲区越界、悬垂指针、重复释放等内存安全问题的发生概率。

这对解释器、运行时和标准库这样的基础设施尤其重要。

其次，是底层模块的性能优化空间。

Rust 并不天然比 C 快，但它可以在保持接近原生性能的同时，提供更强的安全约束。

如果某些成熟的 Rust 实现能够在性能上胜过现有 C 实现，那么 CPython 就有机会直接受益。

zlib-rs 就是一个很好的尝试。

最后，是开发者生态的融合。

过去，Python 开发者可能只需要掌握 Python 和少量 C 语言，就能参与 CPython 的开发。

未来，他们可能需要逐渐理解 Rust。

反过来，Rust 开发者也将拥有一个更加广阔的参与入口，可以直接为 Python 这样的重要基础设施贡献代码。

这可能会让两个社区之间产生更加紧密的联系。

当然，这一切仍然建立在项目能够通过实际工程考验的基础上。

写在最后：Python 不需要成为 Rust，但需要认真对待 Rust

我认为，Rust for CPython 最值得关注的地方，并不是 Python 准备引入一种新语言。

而是 Python 核心团队开始用一种更加开放、务实的态度，重新审视大型系统项目的技术边界。

过去，很多语言社区习惯于讨论：

C 和 Rust，究竟谁更好？

Python 和 Rust，究竟谁更适合系统编程？

但这次 Python Language Summit 给出的答案，实际上更加工程化：

没有必要让一种语言取代另一种语言。真正重要的是，在合适的地方使用合适的工具。

CPython 已经拥有庞大的 C 代码库，没有必要为了追逐技术潮流而全面重写。

但对于新功能、内存安全风险较高的模块，以及能够从 Rust 生态成熟实现中受益的组件，Rust 无疑值得认真考虑。

从 zlib 开始，以可选后端的方式逐步验证，再根据性能、平台和社区接受度决定未来的发展方向。

这是一条谨慎，却又足够大胆的路线。

如果一切顺利，未来的某个 Python 版本中，我们可能会看到这样一个有趣的局面：

开发者仍然使用熟悉的 Python 编写业务代码，CPython 仍然保留大量 C 实现，但在解释器和标准库的底层，Rust 正在承担越来越重要的工作。

而当你下一次执行：

pip install requests

或许根本不会意识到，背后某个负责解压缩数据的底层组件，已经悄然从 C 迁移到了 Rust。

这可能就是一场优秀的基础设施演进应该有的样子：用户几乎感受不到变化，却能持续享受到技术进步带来的收益。

Python 不需要成为 Rust。

但 Python 的未来，很可能需要 Rust。

参考资料

1. Python Language Summit 2026 —— Python 官方博客，2026 年 9 月 30 日。
1. zlib-rs —— Rust 实现的 zlib 兼容压缩库。
1. Rust for Linux —— Linux 内核中的 Rust 支持项目。

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
构建坚不可摧的 Safety Middleware 与飞书人工审批防线
在底层实现 Token 成本审计、链路追踪与自动化跑分评估
从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

文章要点#

Python 为什么需要 Rust？C 语言的舒适区正在变成危险区#

一个值得警惕的数据：type-crash 持续增长#

Rust 能解决什么，又不能解决什么？#

不是重写 Python，而是让 C 和 Rust 协同工作#

Rust for CPython 的演进路线#

为什么第一个目标是 zlib？答案可能让你每天都在受益#

zlib-rs：一个已经经过实战检验的 Rust 实现#

每一次 pip install 都可能变快？#

Rust API 怎么设计？不能只是给 C API 套一层 Rust 语法#

1. 使用属性宏，减少样板代码#

2. 显式传递 Python 解释器上下文#

3. 使用智能指针管理 Python 对象#

4. 使用 Result 表达错误#

5. RAII：离开作用域，自动释放资源#

Python 核心开发者并不都想学习 Rust，这才是最大的现实挑战#

一个非常有意思的争论：Rust API 要不要照顾 C 开发者？#

比 Rust 语法更棘手的，是平台和依赖管理#

问题一：Rust 能覆盖 CPython 支持的所有平台吗？#

问题二：Cargo 依赖会不会成为新的维护噩梦？#

Rust 要通过什么考核，才能真正成为 CPython 的一部分？#

Python 与 Rust 的结合，意味着什么？#

写在最后：Python 不需要成为 Rust，但需要认真对待 Rust#

参考资料#

📚 相关文章