pycc

Compiler landscape · Sources checked 2026-08-07

Python AOT tools solve different jobs.

“Python compiler” can mean a compatibility-focused executable, a CPython extension, a restricted typed Python subset, or a separate static language close to Python. This comparison uses each project's own documentation and keeps pycc's pre-alpha design target separate from released capability.

Tools six projects Evidence official docs Benchmarks none claimed

Start with the artifact

“Native” does not describe one deployment model.

Ahead-of-time compilation happens before execution, but the resulting artifact can still be a CPython extension, an executable that carries CPython runtime components, or native machine code for a restricted Python subset or a different static language model. Those choices affect compatibility, distribution, type behavior, and which Python programs can be accepted.

The table below compares those models. It does not rank performance: no shared, reproducible benchmark suite currently exists in this repository, so speed claims would not be evidence-backed.

Different contracts

Six projects with overlapping output models.

Tool Input contract Output and runtime Current positioning
pycc Typed, standard Python 3.14 is the v1 design target Standalone native executable without CPython for native and pure builds; planned permitted interop bundles a pinned CPython runtime Pre-alpha; v0.1 frontend and native backend implemented with documented gaps; not production-ready
LPython Type-annotated Python subset; accepted programs are intended to remain CPython-compatible AOT binary via LLVM; C, C++, and WASM are also documented backends, with optional CPython interop Alpha; focused on numerical and array-oriented typed Python
Codon A statically compiled language close to Python, with documented differences and additions Native machine code without interpreter runtime overhead High-performance applications that can adopt Codon's language model
Nuitka Python applications with a compatibility-first model Executable or extension; standalone and onefile modes package required runtime dependencies Application compilation, distribution, and CPython ecosystem compatibility
mypyc Standard Python type hints with a strict, gradually typed compiled subset Native C extension imported and run by CPython Alpha; accelerating typed Python modules while keeping CPython interoperability
Cython A Python superset with optional static type declarations Generated C or C++; commonly a CPython extension, with a documented CPython-embedding executable path Extension development, native-library integration, and targeted acceleration

Choose by constraint

The right tool depends on what must stay compatible.

  • Package an existing Python application Nuitka explicitly documents standalone and onefile distribution modes while preserving a CPython-oriented compatibility model.
  • Speed up typed modules inside CPython mypyc produces C extensions from standard type hints; Cython offers a broader Python-superset and C/C++ integration path.
  • Compile a typed Python subset to a binary today LPython is an alpha AOT compiler with LLVM, C, C++, and WASM backends; its accepted subset is intended to remain compatible with CPython.
  • Compile performance-oriented Python-like code without CPython Codon is available today, with deliberate language and semantic differences documented by its maintainers.
  • Target strict standard Python with autonomous deployment Native and pure pycc builds target a standalone runtime; planned permitted interop carries a pinned CPython runtime in the application bundle.

Honest project boundary

pycc is testing a combination, not claiming a win.

pycc aims to combine hard compile-time type enforcement, standard Python syntax, a native executable without an embedded CPython interpreter for native and pure builds, an autonomous bundle for planned permitted CPython interop, and a five-target portability gate. The repository now parses, type-checks, and compiles the implemented v0.1 surface through MIR, LLVM, and its native runtime, and v0.1's own acceptance criteria are met on all five Tier-1 targets. Explicit representation and lifetime gaps remain, the full multi-version conformance matrix is unfinished, and no production release exists.

Do not choose pycc for production today.

Follow the status page if the target model is relevant. Use a mature tool whose current runtime and compatibility contract matches your application if you need to ship now.

Implemented behavior and missing work Current status → Working pipeline and target design Architecture →

Primary documentation

Check each project's own contract.

  • LPython project documentation Typed Python subset, AOT compilation, supported backends, project maturity, and CPython interoperability.
  • LPython source repository Supported platforms, subset compatibility goal, compiler architecture, and current examples.
  • Codon language overview Python differences, static compilation constraints, and native-code model.
  • Nuitka use cases Executable, extension, standalone, and onefile deployment modes.
  • mypyc introduction Type-hint compilation, strict compiled subset, C extensions, and CPython runtime.
  • Cython overview Python-superset language, optional static declarations, and extension-module output.
  • Cython embedding guide The CPython-initializing executable path supported by cython --embed.
  • pycc roadmap Commit-relative implementation status and binary acceptance gates.