What d/Python promises¶
This page lists the promises d/Python is built to keep, and every other page on this site measures it against them. d/Python is Python for d/OS, the operating system that brings modern software to 8-bit home computers such as the Atari 800, the Commodore 64 and the Apple II. The implementation is early and partial, and says so in every table; the promises are not partial. After this page you will know what "done" means for d/Python, and what it will never trade away to get there.
It is Python 3¶
The language is standard Python 3, syntax and meaning, checked against one exact build of CPython that was fixed as the reference before any compiler feature was accepted. "Python 3" alone is not a test target; a version number and the hash of the executable are. Later versions of the language are adopted deliberately, never by accident.
The target is all of ordinary Python: functions, closures, collections, comprehensions, exceptions, context managers, generators, modules, classes and async functions, and descriptors, metaclasses, multiple inheritance, reflection and dynamic imports too. Cost decides the order things are built in; it never removes a feature from the target. Classes and objects are part of the language from the first line, not an optional extra.
Python's rules are not up for negotiation to make the runtime's life easier:
| Python promise | What the implementation must do |
|---|---|
| Integers of any size | Small, fast representations are allowed; when a number outgrows them it must behave exactly as Python says, limited only by available memory. |
| Division, floor division, remainder, truth, evaluation order | Follow the fixed Python definition, negative operands and short-circuiting included; never substitute another language's behaviour. |
str, bytes, collections, identity and two names for one object |
Keep Python's distinctions and mutation behaviour exactly. |
| Function calls and objects | Keep argument binding, the lifetime of default values, closures and object sharing. |
| Exceptions | Keep Python exceptions separate from the platform declining a request; report both the Python outcome and the platform's error. |
Gaps are named, never hidden¶
A machine-readable compatibility table, the ledger, tracks syntax, semantics, builtins, the standard library and the d/OS extensions separately. Every feature carries the clause of the language reference it comes from, its tests, its status and exactly what stands in its way. An unsupported feature gets a clear message or a defined exception; it never compiles into quietly different behaviour. Features that are not yet supported still count against the total, and something supported in part is never called complete.
Compatibility with the standard library and with third-party packages are separate claims from compatibility with the language. Accepting Python syntax does not mean the CPython extension interface exists or that packages from pip run. Resource limits are published and tested, never disguised as machine-by-machine changes to how Python behaves.
One bytecode, every machine¶
A program compiles to .dbc, the compiled program file of d/OS, and runs through the one d/OS runtime, the program that runs your compiled code, with its checks before a program starts, its capabilities, its memory, its scheduling and its application lifecycle. There is no second virtual machine and no escape into native code. No interpreter ships with a program.
Compilation is deterministic: the same source, the same dependencies and the same options produce identical bytes, with no file paths or timestamps inside. The bytecode, runtime, libraries and the list of intents are shared with d/BASIC, d/OS's other language, which is the reference for what a valid compiled file and a complete d/OS application look like; Python's own rules are the reference for how Python behaves, and the two are never traded against each other. Packaging, sealing, finding libraries and launching use the same path as every d/OS application.
Console programs and window programs are equally first-class. A console program never needs a window; a window program uses the shared lifecycle, input and drawing services; and one compiled program may offer both. d/OS calls these the program's two faces.
Every d/OS intent is callable¶
An intent is a named request such as "fill this rectangle" or "play this tone" that the machine carries out however it can, and d/OS keeps an official list of them. One hundred percent means every callable intent on that list, at the revision the compiler was built against, including intents added later, not only the ones that happen to have a convenient wrapper somewhere. Every intent must have a reachable, documented Python binding generated from the official list; exact wire types, bounds, buffers and result counts, with out-of-range integers failing loudly rather than being truncated; the same capability and version requirements as any other d/OS application; tests that run its success and failure paths; and the same test written in both d/BASIC and d/Python for the same call, result and effect.
A new callable intent without tests fails the build. A host that honestly reports it lacks a capability is behaving correctly, but that does not count as proof of the success path. Console and window programs, lifecycle, input, widgets, the game library, files, messaging between programs, libraries, packages and resources are inventoried beside the intents, so "100% intents" cannot hide a missing feature. The intent coverage page is that inventory.
d/OS keeps ownership of windows, focus and priority. Python handlers run within bounded time budgets, long operations give way, and the screen never waits on a program. Where memory lives is invisible to Python authors.
Shared libraries¶
d/Python uses the same compiled libraries as d/BASIC wherever the published calling convention supports the values involved. Python-facing names and wrappers map onto those exports through thin layers that never duplicate a library's implementation. At a shared boundary the wire signature is matched exactly; an export that is incompatible or opaque fails clearly until a bridge for it exists. Libraries written in either language are usable from the other, and d/Python follows the shared widget rules rather than freezing an older drawing model into a second toolkit.
Proof¶
Two compilers agreeing is not proof, because both may share one bug. Every test case must also match an expected result produced independently, and a successful compile, an accepted container or identical bytecode is never a substitute for actually running the program.
The Python suite runs each case under the reference CPython build and under d/Python on the real runtime, comparing results, output bytes, the order of side effects, exception types and cleanup. The shared suite pairs a d/BASIC program and a Python program for one scenario and one reviewed outcome, runs them in the same runtime with the same limits, and compares every typed call, result, declined request and effect; where the promises specify it, the fixed reference cases must produce the same committed bytes. Python is never weakened to make an arbitrary BASIC program compile to the same thing.
Coverage is reported honestly and separately: language, standard library, d/OS features and intents; tests that ran and passed, expected failures, features not yet supported and targets skipped. A check that only compiles never counts. Negative controls prove that the test harness notices a changed output, argument, result, effect, encoding or invalid bytecode. See Conformance and the corpus.
Cost is measured, not promised¶
Compiler size, the memory compilation needs, the size of an application, the memory it uses while running, and how fast and responsive it is are each measured on their own, on named configurations, and budgets are fixed only after representative measurements on the real targets. A smaller program is not an improvement if it quietly changes how Python behaves, moves an unreported cost into every application, or makes the screen stall. See Footprint & Cost.
What "complete" means¶
The promises are kept only when the declared Python compatibility is backed by test programs that run under the reference build; every callable intent and every application feature has the shared tests; the fixed bytecode cases match exactly; libraries and packaged applications run through the normal checks before a program starts; measured cost meets the published budgets; and d/BASIC still passes its own tests. Tests on a desktop host cannot stand in for a real 8-bit machine. None of that is claimed today; What Runs Today is the table of what is.
Licensing¶
The d/Python compiler and runtimes are written to ship under the MIT licence, and the parser is RustPython's under its MIT notice. Python's reference implementation and documentation are under the PSF License Version 2, whose notice and origin requirements are preserved for anything reused and never relabelled. Python is a trademark of the Python Software Foundation; d/Python is not affiliated with or endorsed by the PSF.