一个叫can1357的开发者,给Python写了一个编译器,取名pon。听起来像PyPy的又一个变种,但它做的事情更狠:没有字节码,没有解释器,连引用计数都扔了。源代码用ruff解析器读进来,统一转成一份IR,再交给Cranelift编译成机器码——要么在进程里JIT即时跑,要么直接AOT打包成一个独立可执行文件。内存交给一个叫Green Tea的垃圾回收器管,不再靠CPython那套引用计数。
正确性怎么保证?字节级差分测试。pon跑出来的输出,要和CPython 3.14.0跑出来的一个字节都不差。现在能通过这个测试的语料库,JIT路径是244个模块,AOT路径是206个模块,并且每次提交都会把这个数字锁成一条"floor",低于这个数字CI直接不让过。
这个组合,之前没人真正凑齐过
Python加速这条路,已经挤了不少玩家,但仔细看会发现,他们各自只占了半张地图。
Nuitka把Python编译成C代码再链接,跑得比解释器快,但骨子里还挂着libpython,语义上离不开CPython这套引用计数体系——严格说不算"无解释器"。Codon和Mojo走的是另一条路:真正编译成原生机器码,不背CPython的历史包袱,但代价是它们不完全是Python,语法像,语义不一定一样。PyPy倒是长期活跃,JIT加速热点代码效果不差,但骨子里还是一个解释器环境。
pon想同时要两样东西:Codon级别的"扔掉解释器",加上Nuitka级别的"和CPython长得一样"。这两件事分别都有人做到过,同时做到,目前只有pon在自称做到。
244和206,说明的是起点而不是终点
conformance floor这套机制本身设计得干净:语料库文件一旦进仓库就不能改,新覆盖率必须是新模块,而且要先跟python3.14跑一遍确认字节相同才能收进清单。CPython自己的问题(不是pon的锅)也单独记账,不藏着。这种做法值得认可,至少态度是老实的。
- 结论.测试机制设计得诚实,但244个模块相对CPython标准库和完整测试套件的体量,只能算刚起步的验证范围。
真正的坎在roadmap里写得很清楚:CPython自带的完整测试套件Lib/test还"正在攻坚",作者自己说这是"接下来要啃的硬骨头"。也就是说,现在能过关的244个模块,是精选出来能过的,不是全量扫过去能过的。这个区别很关键——demo阶段的漂亮数字,和生产级的兼容性,中间还有一段距离。
官方也在提速,但走的是另一条路
容易被忽略的一点是,CPython官方在3.14里自己也在动手:可以用--enable-experimental-jit编译出实验性JIT,还引入了新的tail-call解释器设计。这条路走得保守,进展也不算顺——社区反馈这套实验性JIT的构建和平台兼容性还有不少毛病。
pon和CPython官方JIT不是一场赛跑,是两条平行线。官方选择在解释器内部小步提速,尽量不破坏现有的C扩展生态;pon选择另起炉灶,连引用计数都换掉,赌的是能换来更大的性能空间。哪条路线先跑通,现在都还没有答案。
敢换掉引用计数,是胆子;能不能保住C扩展生态,是命门。
换掉引用计数换来的Green Tea GC,对纯Python代码友好,但CPython生态里大量C扩展是靠引用计数语义写的,这块兼容性原文里没有细说,也是这类项目历史上最容易翻车的地方。
谁该等等看,谁该现在就试
对性能敏感的团队,pon现在还不是能用的东西——它自己都承认stdlib build-out和CPython完整测试套件还在路上。对关注Rust和Cranelift生态的人来说,这倒是一个值得盯的技术验证案例:一套IR吃两个后端(JIT和AOT),tier-0保正确性、tier-1做类型特化再加OSR,这套分层思路本身是扎实的工程设计。
- 风险.目前所有conformance数字都来自项目自己的仓库,联网范围内找不到第三方复现或独立跑分,可信度还停在"开发者自证"这一步。
一个人写的编译器,能不能扛住CPython生态几十年攒下来的边角案例,不是靠README里的数字说服人,是靠外部社区拿真实代码去跑、去挑刺。这一步,pon还没走到。