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.
Arithmetic, comparisons, assignments, calls and returns,
recursion, if/while/for
with range, booleans, floats, strings, and basic
f-strings are parsed and checked.
check supports validated human and JSON
diagnostics. build and run compile
the implemented v0.1 surface; other documented commands
remain planned.
Public annotations are required, Any is
rejected, and monomorphic private-helper signatures are
inferred and materialized before MIR.
Parser failures use L0001; byte-exact CLI
snapshots cover T0001, T0002,
T0021, T0022,
T0023, and T0024.
Linux x64/arm64, macOS x64/arm64, and Windows x64 build and test in CI. A macOS arm64-to-x64 cross-host path is verified.
Pull requests must keep the current Rust implementation at 100% line and region coverage before the protected branch can merge.
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.
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).
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.
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 checkexits 0 for a name assigned only underif Falseand then read (false-success; CPython raisesNameError). - #123:
pycc checkrejects"ab" * 3withT0021(valid standard Python; CPython printsababab). - #145: multi-argument
printevaluates 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 runaborts (exit 101) for bigint-valuedrangeinstead of raising a user-level exception. - #148:
pycc runaborts with a codegen panic for large integer literals like2**62. - #150:
pycc runaborts with a non-unwinding Rust panic forrange(..., step=0)instead of raisingValueError.
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.
- End-to-end v0.1 backend tests Compile and execute the currently supported programs.
- Type-checker implementation Strict public signatures, local inference, calls, control flow, assignments, and returns.
- CLI diagnostic snapshots Byte-exact human output for the shipped frontend errors.
- Required CI workflow Build, test, coverage, performance, and Tier-1 target evidence.
- Commit-relative roadmap The authoritative current-status table and acceptance gates.
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.