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 according to the evidence found in its source checkout during the build:

test-verified

The cited test file (.NET) or function (Go) exists. This does not mean the test was run.

claimed

The ledger asserts an implementation or test without a resolvable citation.

unknown

The ledger records no implementation status for this row.

Per-port summary

C# and Go publish per-symbol ledgers that are entirely pre-triaged; on this build, all 626 C# rows and all 1588 Go rows resolve as test-verified: the cited evidence (a test file for C#, 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 C#'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 using the same mapping as C#'s module field. “No rows” means the ledger has no entries for that module; for C#, most of the _internal/_vendor rows are that by declared scope (public-API-only), not by omission.

Per-ledger notes

• C#: Covers the public API extracted in python-public-api.json. Python's _internal and _vendor modules are outside this ledger's scope.
• Java: Module counts use python-api.md. test-map.md identifies pytest cases and doctest chunks instead of symbols, so its counts are reported separately: 1458 rows, with statuses {"planned parity":1454,"source-declared partial non-execution":1,"deliberate Java correction":3}. Its 3 "deliberate Java correction" rows assert implementation but cite methods on the missing PythonBehaviorParityTest class. They count as claimed in the port total only. Server.attached_sessions has two evidence entries, so row counts can exceed the number of distinct corrections.
• Swift: 712 of this ledger's 1326 entries are inherited dataclass fields, counted once for each inheriting subclass, mostly in libtmux.neo. These repeated entries increase row counts without increasing the number of distinct Python symbols.
• Go: the "Python revision" column above reads "not recorded". See the revision-skew note above for what Go's manifest records instead.