Evidence page · Updated 2026-08-07

What pycc can do today.

pycc is a pre-alpha ahead-of-time compiler for typed Python 3.14. This page separates working, repository-tested behavior from the larger design contract. It is not a release announcement.

Milestone v0.2 acceptance criteria met; v0.3 in progress Acceptance v0.1 and v0.2 both fully met Readiness pre-alpha

Current implementation

The frontend and native backend cover v0.1 and v0.2, with v0.3's class model core landed.

pycc check runs the parser → HIR → strict type checker without entering code generation. The build/run path lowers the same implemented language surface through MIR, LLVM object generation, host linking, and execution of a native binary.

Frontend language surface Implemented v0.1 subset

Arithmetic, comparisons, assignments, calls and returns, recursion, if/while/for with range, booleans, floats, strings, and basic f-strings are parsed and checked.

Compiler driver Build, run, check, version

check supports validated human and JSON diagnostics. build and run compile the implemented v0.1 surface; other documented commands remain planned.

Type system Strict checking and inference

Public annotations are required, Any is rejected, and monomorphic private-helper signatures are inferred and materialized before MIR.

Diagnostics Validated frontend codes

Parser failures use L0001; byte-exact CLI snapshots cover T0001, T0002, T0021, T0022, T0023, and T0024.

Portability Five native CI targets

Linux x64/arm64, macOS x64/arm64, and Windows x64 build and test in CI. A macOS arm64-to-x64 cross-host path is verified.

Quality 100% lines and regions

Pull requests must keep the current Rust implementation at 100% line and region coverage before the protected branch can merge.

Collections and generics v0.2 acceptance criteria met

list, dict, set, and tuple, plus comprehensions, slicing, methods, and generics, match pinned CPython output on all five Tier-1 targets, and --release clears its nbody-vs-CPython speedup floor on every target.

Class model core v0.3 in progress

Ty::Instance, HIR class definitions, and single-class instantiation, attribute access, and methods have landed. Inheritance, @property, dataclasses, enums, protocols, structural pattern matching, and custom exceptions remain planned.

Scope boundary

pycc still has explicit implementation gaps.

The current backend deliberately rejects bigint comparisons and several bigint arithmetic operations and float formatting outside the accepted v0.1 range. Unary operators are rejected earlier by HIR lowering with a spanned C0001 capability diagnostic, including under pycc check. Unbound string temporaries and function-scoped string values can still leak until ownership analysis lands, and the same leak-only policy currently covers list, dict, and set containers and class instances (D-107/D-124, extended by D-154) — none of them carries a real reference count yet. set[int] has no membership test; in, not in, is, and is not all route through the generic C0001 diagnostic. tuple[...] slicing remains deferred (D-118) until its result shape can be expressed without a fixed-arity struct's fixed bounds. Optional and narrowing still have no grammar surface, and type diagnostics still use the documented line-1/column-1 placeholder span (D-043).

Do not use pycc in production.

HIR and type diagnostics still use placeholder source positions, safe help suggestions are not populated, and documented gaps may still fail at explicit pre-alpha boundaries. Landing-page examples outside the implemented v0.1 surface remain design targets unless marked otherwise.

Known correctness defects in the named v0.1 surface.

The accepted boundaries above are deliberate scope limits. The following are open defects inside the named current surface, not deliberate scope limits — programs that pass pycc check or run under pycc run but produce wrong results or abort where CPython succeeds:

  • #118: pycc check exits 0 for a name assigned only under if False and then read (false-success; CPython raises NameError).
  • #123: pycc check rejects "ab" * 3 with T0021 (valid standard Python; CPython prints ababab).
  • #145: multi-argument print evaluates arguments in a different order than CPython, producing silently different output.
  • #146: supported bigint add/sub in a constant-magnitude loop leaks native memory linearly.
  • #147: pycc run aborts (exit 101) for bigint-valued range instead of raising a user-level exception.
  • #148: pycc run aborts with a codegen panic for large integer literals like 2**62.
  • #150: pycc run aborts with a non-unwinding Rust panic for range(..., step=0) instead of raising ValueError.

This list is not exhaustive — other open issues define additional source-order, call-target, and conversion boundaries. Milestone acceptance proves the five binary gates are green; it does not prove every combination inside a broad feature label is correct.

Primary sources

Claims link back to executable evidence.

Planned next

The rest of v0.3's class model and the full conformance matrix are next.

v0.1 and v0.2's acceptance criteria are both met, and v0.3's class model core has landed — see Implemented now above for what that covers today. Still ahead for v0.3: inheritance, @property, dataclasses, enums, protocols, structural pattern matching, and custom exceptions. Beyond the class model, the full multi-version conformance matrix, differential fuzzing, and corpus testing remain planned test-depth work carried over from v0.1 and v0.2. See the delivery plan for the exact sequence.

The 100% line/region coverage gate and the required frontend-perf-gate (currently a greater-than-7.0% regression floor, enforced by a paired predecessor/candidate measurement — see the roadmap for the full mechanics) stay required through all of this work. The implementation gaps listed above are accepted boundaries the met v0.1/v0.2 milestones' acceptance criteria never required closing, not outstanding blockers.