Parity

Python is the reference implementation; every other port tracks how much of its public surface it covers.

How each port is built

Per-symbol parity

Four ports publish a per-symbol Python-parity ledger, each in its own format (Rust, C++ and TypeScript keep trackers too, in three more shapes not sampled here). Every cell below is marked by what its ledger's own cited evidence resolves to on this machine, not by how confident the ledger's prose sounds:

test-verified

The cited test (file, for .NET; function, for Go) exists in that port’s checkout.

claimed

An implementation or test is asserted, but the ledger cites nothing resolvable.

unknown

The ledger disclaims implementation status for this row, or carries no status field at all.

Per-port summary

.NET and Go publish per-symbol ledgers that are entirely pre-triaged; on this build, all 626 .NET rows and all 1588 Go rows resolve as test-verified — the cited evidence (a test file for .NET, a test function for Go) exists in that port's checkout. Java's and Swift's ledgers carry no per-symbol implementation-status field at all: Java's by explicit disclaimer in its own source files ("a row's presence says Python has it, not that Java does" / "a catalogue, not a status report"), confirmed here by checking that the contract-test classes those files cite (not found / not found) don't exist in the checkout; Swift's by the absence of any Swift-side status field across all five of its parity files.

By Python module

Rows are the union of modules across all four ledgers. Only .NET's ledger has its own module field, used directly; Go, Java and Swift have none, so their rows are derived mechanically from each entry's source-file path instead (see scripts/normalise-parity.mjs's deriveModule) — the same rule for all three, so their keys line up with each other and, for files .NET's ledger also covers, with .NET's own field. An em dash means the ledger has no rows at all for that module; for .NET, most of the _internal/_vendor rows are that by declared scope (public-API-only), not by omission.

Per-ledger notes

• .NET: Scoped to public API surface only (python-public-api.json in the same directory is the matching 626-symbol extraction) — no rows at all for Python's _internal/_vendor modules. A module missing here is out of this ledger’s declared scope, not an omission.
• Java: Per-module rows below come from python-api.md only — test-map.md is keyed by pytest node IDs and doctest chunks, not Python symbols, so it cannot be bucketed by module; its own totals are reported once at the port level instead: 1458 rows, status counts {"planned parity":1454,"source-declared partial non-execution":1,"deliberate Java correction":3}. The 3 rows status "deliberate Java correction" are test-map.md’s own prose "defect decisions" (2 decisions, 3 rows — Server.attached_sessions is cited under two evidence keys) that the ledger says *are* implemented; each still cites a PythonBehaviorParityTest method, the very class confirmed absent from the checkout, so this script marks them "claimed" rather than upgrading them on the strength of the status label alone. Folded into the port tally below, not counted twice against python-api.md’s own module rows.
• Swift: 712 of this ledger's 1326 entries are kind "inherited-dataclass-field" — the same Python dataclass field counted again for every subclass that inherits it (libtmux.neo, almost entirely), not that many distinct symbols. A module row where Swift’s count runs several times another port's for the same file is this, not several times the actual surface.
• Go: the "Python revision" column above reads "not recorded" rather than a guess — see the revision-skew note above for what Go's manifest records instead.