Conformance¶
This page explains how d/Python checks that it really behaves like Python, and what "tested" means on this site. After it you will know what every test is compared against, how the shared tests with d/BASIC work, how far intent coverage has come, and what "complete" would require.
Two compilers agreeing with each other proves little: they may share the same bug. So every test must also agree with an independent expected result, and compiling successfully, producing a valid file, or matching bytecode is never a substitute for actually running the program. That sentence comes from d/Python's design rules, and the whole test suite is built around it.
The reference build¶
The Python reference is one exact build: CPython 3.9.6 (3.9.6 (default, Apr 30 2025, 02:07:18), Clang 17.0.0), whose executable was recorded by its SHA-256 hash before any compiler feature was accepted. The test gate checks the full sys.version and the hash, and it will not silently skip if that build is missing. Newer Python versions will be adopted explicitly, as entries in the compatibility table. The official Python Tutorial and CPython's own Lib/test are where new tests are drawn from; tests borrowed from upstream keep their licences and their origin, and none is relabelled as d/Python's own.
The corpus¶
Sixty-six independently written programs, each with one reviewed expected output, each run under the reference build and through d/Python, compiled to bytecode and executed by the real d/OS runtime, with the two outputs compared byte for byte. All sixty-two of the single-file cases were run through the browser toolchain when this site was built; the corpus page shows each verdict and each expected output. Beyond the corpus, focused tests cover boundaries and combinations: negative arithmetic, large integers, the printability of every Unicode code point, aliasing, nested closures, argument binding, inheritance, generator expressions, exception unwinding and cleanup order.
The shared BASIC/Python suite¶
d/BASIC is d/OS's other language, and it shares the same runtime. Each shared test is written in both languages, with one scenario, one set of host services and scripted input, and one reviewed expected outcome. Both versions run in the real shared runtime with the same permissions, limits, library bytes and scripted environment. Two kinds of check are required:
| Check | Exact assertion |
|---|---|
| Behavior and effects, every shared test | both runs equal one independent expected outcome: console and file bytes, return values, DOBJ data (the typed object every message between programs carries), the ordered intent calls with their typed arguments and results, declined operations and exit status, plus state or rendered output where relevant |
| Bytecode bytes, the exact-emission tests | pairs of programs specified to translate to the same sequence of typed operations produce the same bytes under a fixed optimization profile, compared with an independently reviewed fixture as well as with each other, and then executed |
Equivalent behavior does not require identical instructions for every program: the two languages differ in how numbers, strings, objects and parameters work, and Python's rules are never weakened to make an arbitrary BASIC program compile to the same bytes. A test that compares output bytes chooses explicit equivalent formatting in each language and fixes the expected bytes. A d/BASIC window and window.py run the same open, draw, key, repaint, close scenario against one set of reviewed pixel hashes from the native renderer.
Intent parity¶
An intent is a named request such as "fill this rectangle" or "play this tone" that the machine carries out however it can. d/Python promises that 100% of the callable intents in the official list can be called from Python and have the same success and failure tests written in both languages and passing. Continuous integration joins the list to the bindings and the coverage, and a new callable intent without coverage in either language fails the gate. A host correctly reporting that it lacks a provider (the part of the host that supplies files, or sound, or the network) is valid behavior, but it is not proof of success: a deterministic provider must actually carry out the intent. Today: 191 intents can be called, 86 have passing success tests; the coverage page lists them.
Gates¶
- Python language, standard library, d/OS feature and intent coverage are each reported separately, and within each, passes, expected failures, features not yet supported and skipped target runs are reported separately. A compile-only check never counts as coverage.
- The d/BASIC suite, with its bytecode and trace checks, is kept passing through every change to the shared compiler stages.
- Deliberate failures prove that the harness notices changed output, a changed intent argument, a wrong result, a missing side effect, invalid bytecode and a changed bytecode encoding.
- The list of built-in names is compared with the reference build's on every run, and each entry's test references are checked.
- The ledger, the machine-readable compatibility table, is what the site reads, and a feature that is not yet supported still counts in the denominator.
What was tested¶
Every claim on this site traces to dated, preserved test results. The first macOS implementation on 11 September 2026: a full verification run, the game's reviewed pixels, and a scheduling defect found by the game and fixed in the shared runtime with a proof for every budget from 1 to 32. The follow-on batches for text, containers, sets, sequences, iterators, closures, sorting, protocols, context managers, packages and input. The release of 12 September 2026: 416 tests passing, 77 measured programs, and the verified macOS kit. The browser playground checks of the same day: WebAssembly and browser client tests, recorded browser observations, and the failed attempts that led to them. And the Linux and Windows runs of the same day: the actual exported Python and BASIC compilers with the shared runtime compared byte for byte, tests that the two languages see the same list of intents, an exact 258-pixel explanation of a button-contrast interaction the interface check found, and the one negative result kept in the open: input() on Linux is declined because its native standard-input endpoint is macOS-only. Failed attempts are kept beside their corrections; nothing was rerun to make a document look better.
What "complete" would mean¶
d/Python may call its promises complete only when every claim in its compatibility table is backed by tests run against the reference build; every callable intent and every d/OS application feature has the shared two-language tests; the exact-bytecode tests match; calls into shared libraries and packaged applications run through the normal checks a program passes before it runs; measured size and responsiveness meet published budgets; and d/BASIC still passes its own suite. Tests on a development machine cannot establish completion on the real 8-bit hardware. None of that is claimed today: the compatibility table says supported in part, and so does this site.