Python 的实验性 JIT 将被移除
Python 的核心开发者已决定移除 CPython 中实验性的即时编译器（JIT），理由是长期维护前景不明、实际加速有限，以及它会给这个被广泛使用、对安全敏感的运行时增加复杂性。评论者分成两派：一派认为这是保护稳定性和工具兼容性的健康治理；另一派则认为这是扼杀雄心勃勃的性能工作、使其几乎不可能进入主实现的官僚主义。许多人提到 PyPy、GraalPy、Cython、Numba，或用更快的语言整体重写作为替代；同时也感叹 Python 生态和 C API 的怪癖，使得这种语言的流行与顶尖性能很难兼得。
放弃 JIT 的总体反应
- 许多人表示失望；他们原本希望 JIT 能显著加速“纯 Python”，并减少重写为 Cython/Rust 的需要。
- 也有人认为这一决定是合理的，因为相较于巨大的复杂性和维护负担，速度提升却很有限（常被提到大约 ~10%）。
- 还有人把这看作 Python 又一次失败的 JIT 尝试（继 Psyco、Unladen Swallow 等之后），进一步加深了对 CPython 什么时候也难以拥有一个成熟、内建 JIT 的悲观看法。
流程、治理与“官僚主义”
- 一方认为委员会式流程和严格的 PEP 要求扼杀了一个原本很有前景的实验，理由是诸如广泛工具支持和成功指标之类的“毒丸”要求。
- 另一方则认为流程本就该如此运作：一旦某个东西进入
main，它就必须有明确的范围、维护计划和兼容性方案；开放式实验不应进入这门全球基础设施语言的核心。 - 对于这究竟是“官僚主义”还是成熟生态所必需的治理，存在分歧。
Python 的 JIT 面临的技术挑战
- Python 极强的动态性被视为核心问题：
__dict__、__class__重绑定、monkey-patching、元编程、pytest 字节码重写、C 扩展以及内省 API，都会使优化复杂化。 - 有人认为，这些并不比 JavaScript 或 Ruby 的语义本质上更难，而成功的 JIT（V8、LuaJIT、PyPy、GraalPy）表明，只要投入足够，JIT 是可行的。
- 也有人指出，CPython 的 C API 泄露了实现细节，使得像 JIT 和移除 GIL 这样的深层改动尤其冒险。
当前的性能现状与已有替代方案
- 常被提到的方案包括：C 扩展、Cython、Numba、mypyc、PyPy、GraalPy、Rust（通过 PyO3）以及用 Go 重写。
- 批评意见：这些方案彼此分散，各有局限（版本滞后、C API 问题、受限子集、部署复杂性）。许多人仍然想要“只是更快的 CPython”。
- 也有人认为 Python 已经触及实际极限：如果性能是核心需求，那答案就是把热点路径或整个系统重写为更快的语言，甚至可以借助 AI 来完成。
安全性与可靠性顾虑
- 有人支持避免使用 JIT，因为 JavaScript 引擎和 PHP 在安全方面已有前车之鉴；他们更看重 CPython 更简单的字节码虚拟机以及相对较低的 CVE 数量。
- 也有人回应说，Python 很少运行不受信任的代码，因此 JIT 特有的利用风险，相比已经由 C 扩展引入的安全问题，并没有那么有说服力。
替代方向与子集
- 有几位建议，只有更严格、带类型的 Python 子集并配合 AOT/JIT（例如“Static Python”、类似 Mojo、CinderX 风格）才可能成为实现大幅提速的可持续路径。
- 也有人怀疑，在 Python 的文化和现有动态特性之下，这样的子集是否能标准化，认为那将引发大量无休止的争论。