pon 是一个用 Rust 编写的 Python 3.14 原生编译器与运行时项目，目标是将 Python 代码直接编译为机器码，而不是通过解释器或字节码执行。它支持 JIT 即时编译和 AoT 提前编译，前端使用 ruff parser 解析 Python 3.14，后端基于 Cranelift 生成机器码，并自带运行时、垃圾回收器 Green Tea GC、对象模型、内建函数和一致性测试框架。项目愿景类似“Python 生态中的 bun/v8”：更快的运行时、单文件原生可执行程序、内置包管理与工具链。目前处于重度开发阶段，已有端到端 JIT/AoT 能力，但 CPython 兼容性和标准库覆盖仍在推进中。
适用领域
编程语言运行时 / Python 编译器 / JIT 即时编译 / AoT 原生编译 / Rust 系统编程 / Cranelift 编译后端 / 垃圾回收器 / Python 生态工具链 / CPython 兼容性测试 / 高性能脚本语言执行
配置难度
高。该项目涉及 Python 语言语义、编译器前端、IR 设计、Cranelift 后端、JIT/AoT、运行时 ABI、对象模型、垃圾回收、标准库兼容、包管理器和差分测试。普通应用开发者上手使用简单 demo 不难，但若要参与核心开发，需要较强的 Rust、编译原理、虚拟机和 CPython 语义背景。
商业价值
中到高，但偏长期研发价值。短期看，pon 更适合作为编译器、运行时和 Python 性能优化方向的技术研究项目，不适合立即在商业生产系统中替代 CPython。中长期如果其 CPython 兼容性、标准库、包生态和性能目标能够兑现，将具备明显商业价值：例如 Python 服务加速、脚本原生打包、边缘部署、无解释器分发、数据计算性能提升、无 GIL 多线程运行时等。但目前最大约束是成熟度、许可证缺失、生态兼容和测试覆盖尚未完成。
01
技术亮点
- 同时支持 JIT 和 AoT：pon run 可即时编译运行，pon build 可生成原生可执行文件。
- 没有传统解释器和字节码路径，代码从 Python AST 降级到共享 IR，再由 Cranelift 生成机器码。
- 使用 Rust 实现，模块化 workspace 结构清晰，包括 IR、codegen、JIT、AoT、runtime、GC、ABI、conformance 等 crate。
- 使用 ruff parser 作为 Python 3.14 前端，避免从零实现 Python 解析器。
- 采用 Green Tea GC，而不是 CPython 的引用计数模型，有助于探索不同的 Python 内存管理设计。
- 强调与 CPython 3.14 的字节级输出一致性，并提供差分测试、fuzzing、AoT parity floor 等质量门禁。
- 性能基础设施已经布局，包括后台编译、OSR、inline caches、type feedback 等。
- 有远大路线图：通过 CPython 测试套件、完善标准库、提升性能、实现更成熟的 AoT 单文件体验和无 GIL 运行时。
- 内置 uv 风格包管理器设计，计划覆盖 pyproject.toml、PyPI simple index、wheel、sdist、editable install、VCS requirements 等场景。
02
目标用户
- 对 Python 运行时、解释器、编译器实现感兴趣的开发者
- Rust 系统编程和编译器工程师
- 希望研究 Python JIT/AoT 编译技术的研发团队
- 关注 CPython 性能瓶颈和替代运行时的技术人员
- 需要将 Python 脚本打包成原生可执行文件的实验性用户
- 语言虚拟机、GC、IR、Cranelift 方向的研究者
- 对无 GIL Python 运行时或多线程 Python 感兴趣的开发者
03
配置要求
- 需要 Rust nightly-2026-04-29，项目通过 rust-toolchain.toml 固定。
- 需要 Cargo，且依赖版本由 Cargo.lock 和 workspace.dependencies 统一管理。
- Cranelift 相关 crate 固定为 0.133.1，不能随意升级。
- ruff parser 固定为 git tag 0.14.0，并以 PythonVersion::PY314 解析。
- 一致性测试依赖 CPython v3.14.0 作为参考实现。
- 运行差分测试时建议设置 TZ=UTC 和 PYTHONHASHSEED=0，以保证输出字节级一致。
- AoT 编译和链接可能需要本机 C 工具链、链接器以及目标平台支持。
- 项目当前面向 Python 3.14，不能假定其兼容 Python 3.10、3.11、3.12 或 3.13 的所有行为。
- 部分高级能力如包管理器、完整标准库、性能优化层仍在开发中，不适合直接作为生产运行时替代 CPython。
04
适用场景
- 将简单 Python 3.14 脚本通过 JIT 方式直接编译并运行
- 将 Python 文件 AoT 编译为本地原生可执行程序
- 研究 Python 前端解析、IR 降级、Cranelift 代码生成和运行时 ABI 设计
- 对比 pon 与 CPython 的输出一致性和语言兼容性
- 实验 Python 运行时中的 GC 方案，尤其是非引用计数内存管理
- 构建高性能 Python 执行引擎或定制语言运行时的技术参考
- 探索 Python 包管理器、运行时、编译器一体化工具链的设计
05
部署与配置
- 安装 Rust 工具链，项目使用 rust-toolchain.toml 固定 nightly-2026-04-29，MSRV 为 rust-version 1.94.0，edition 2024。
- 克隆仓库：git clone https://github.com/can1357/pon.git && cd pon
- 确认 Rust nightly 工具链可用，cargo 会根据 rust-toolchain.toml 自动切换到项目指定版本。
- 创建测试 Python 文件，例如：printf 'def add(a, b):\n return a + b\n\nprint("hello, world")\nprint(add(2, 3))\n' > hello.py
- 通过 JIT 运行：cargo run -p pon -- run hello.py
- 通过 AoT 构建原生可执行文件：cargo run -p pon -- build hello.py -o hello
- 运行编译产物：./hello
- 可选：运行快速质量门禁：bash scripts/gate.sh fast
- 可选：运行完整测试门禁：bash scripts/gate.sh full
06
风险与注意事项
- 项目仍处于重度活跃开发阶段，不适合作为生产环境 CPython 替代品。
- README 中状态信息存在一定不一致：表格中提到 JIT 244 个模块、AoT 206 个模块，但 Status 部分又写 JIT 209、AoT 172，实际兼容性应以仓库中的 floor 文件和 CI 为准。
- CPython 完整测试套件尚未通过，标准库覆盖仍有大量工作。
- Python 动态语义复杂，完整兼容 CPython 的难度极高，未来维护成本很大。
- AoT 编译 Python 在动态导入、反射、C 扩展、包生态兼容方面可能遇到长期挑战。
- 未声明 license，商业或二次分发使用存在法律不确定性。
- 依赖 nightly Rust 和固定版本 Cranelift/ruff，工具链稳定性和升级成本较高。
- Green Tea GC 与 CPython 引用计数行为不同，可能在析构时机、资源释放、C 扩展兼容性上产生差异。
- 包管理器尚未纳入 runtime gates，说明该部分成熟度可能较低。
- 项目星标数量约 306，社区规模较小，长期维护可持续性需要观察。
2026-07-09
第26名
新收录 · github_search
2026-07-08
第27名
新收录 · github_search
