Frequently asked questions

Short, straight answers to the questions people ask first about d/Python: how much of Python it is, what a compiled program is, what works in the browser, how it relates to d/BASIC and d/OS, the licences, and what comes next. After this page you will know what to expect before you try anything.

What is d/Python, in one sentence?

d/Python is Python 3, compiled by a compiler written in Rust into one small bytecode that runs, with windows, widgets and intents, in your browser and on your Mac today, on Windows and Linux as their hosts arrive, and on the Atari 800, Commodore 64 and Apple II under d/OS, the operating system that brings modern software to those 8-bit home computers, all without shipping an interpreter.

Is it really Python?

The syntax is Python 3, read by the RustPython parser. The meaning is Python 3's, checked case by case against one exact build of CPython, 3.9.6, the reference build every test is compared with: floor division and remainder with negative numbers, integers of any size, two names for one changeable object, argument binding with positional-only and keyword-only parameters, default values worked out once, inner functions sharing variables with the function around them, exceptions unwinding through finally, and the order a context manager enters and exits. All of it is checked by a set of test programs that really run, whose expected output was reviewed independently and then confirmed under CPython.

What it is not, yet, is all of Python. The compatibility table has 45 rows and none is marked complete. Floats beyond literals, true division, generator functions, async, descriptors, metaclasses, multiple inheritance, the standard library and open() are not yet supported, and each row says what stands in the way. The compiler stops at the line and column and tells you exactly what is missing, rather than compiling something slightly different. See What Runs Today.

Is it MicroPython, or CPython compiled to WebAssembly?

Neither. No CPython code runs anywhere. The browser build is the Rust compiler and the shared runtime, the program that runs your compiled code, as two WebAssembly modules, and a program is a compiled .dbc file plus the .dbl support libraries it uses. What d/Python promises names MicroPython as a possible reference for how to build things, and explicitly not as the ceiling on compatibility; nothing of it is in the build.

Why 3.9?

Because a test you can repeat needs one exact build to compare against. "Python 3" is not a test target; 3.9.6 (default, Apr 30 2025) with a fixed executable hash is. The conformance check compares both sys.version and the SHA-256 of the executable, and it will not quietly skip when that build is missing. Later versions of the language are adopted deliberately, as rows in the compatibility table, when a feature that needs them is implemented.

Why won't the compiler accept x = float("1.5")?

Because float arithmetic beyond a literal is not yet supported, and d/Python's promises say an unsupported feature must get a clear message or a defined exception, never a silently different result. The d/OS runtime, the program that runs your compiled code, inherited its number types from QuickBASIC, and d/Python is forbidden from giving Python those rules just to get code out the door. Until Python's float rules are implemented and proven against the reference build, float(), /, round() and float formatting are stopped with a message. Integers are the opposite story: they have no size limit today, live in a shared library, and every //, %, **, shift and bitwise case is proven.

Why does it say "mixed element types in a Python list need the tagged-value adapter"?

Today's compiler works out one element type for each list, dictionary and set, and produces code specialised for it. [1, "a"], or a list holding two different classes of your own, needs a way to carry a type tag with each value, and that does not exist yet; the message names the missing piece. Tuples are different: a tuple's shape is fixed, so (1, "a", [2]) is fine. The same type inference is why an empty container must have a known shape before it is printed inside a loop; writing items = [0] and then items.clear() is the idiom the compatibility table documents until inference across a whole scope lands.

How does this relate to d/BASIC?

They are siblings. d/BASIC, d/OS's other language, came first and is the reference for what a valid compiled .dbc file looks like and how a d/OS application fits in: console and window programs, lifecycle, intents, libraries, packages, seals. When d/Python started, the code that emits, optimizes, relocates and checks bytecode was lifted out of the d/BASIC compiler into a shared back end that both languages use; d/BASIC kept its old names as aliases and its whole test suite kept passing. The shared conformance suite runs the same test written in both languages in the same runtime and compares every call and effect. Libraries written in either language are meant to be callable from the other through one published calling convention. Nothing about Python's rules was bent to make the bytecode match; where the two languages differ, the paired tests choose equivalent operations and fix the exact bytes.

Can I play with it without installing anything?

Yes. The playground runs the real compiler and runtime as WebAssembly, on your own machine, and uploads nothing. Console programs, input(), windows, on-screen widgets and the tic-tac-toe game all work in the browser. What the browser build does not do is attach the parts of the host that supply files, the network and sound. Those calls compile, they are proven natively on macOS, and here they are declined before the program starts, with the reason named. Math and the SHA-256 hash are part of the shared runtime and work in the browser.

Where do I download the compiler?

There is no packaged public download yet. The dpython command line (check, build, run, inspect, trace, bindings, package) exists and builds on macOS; The macOS Kit describes the folder it ships in, which you can move anywhere, with both programs, compiled examples and checks that it still works. A signed, notarized public kit comes next.

What is a .dbc?

The compiled program file of d/OS: a checked, versioned bytecode image with a table saying whether the program is a console program, a window program or both, a list of requirements the loader checks before the first instruction runs, and exact identities for the shared libraries it depends on. dpython inspect prints its code, constant pool, static data and stack figures using a separate reader of its own. The same file runs on the browser runtime and the desktop runtime. See Compiler & Artifacts.

Does the same .dbc run on a real Atari, C64 or Apple II?

That is a question for the platform rather than for the language, and this site will not answer it on the platform's behalf. d/Python produces the same compiled file d/BASIC produces, so it goes wherever that file goes. Proof on real hardware lives with d/OS, and d/Python's promises say plainly that tests on a desktop host cannot stand in for a real machine.

What about Windows and Linux?

The compiler, the shared runtime and the command-line test suites pass on both (test runs of 12 September 2026), and the browser build runs anywhere a browser does. Two things are still macOS-only, and the test results say so: the raw terminal path behind input() (on Linux, 65 of the 66 test programs pass; the one that calls input() is declined and says why, rather than faked), and the native window host. Window hosts for the other desktops are the platform's next steps.

What does "100% intent coverage" mean, and is it done?

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. d/Python's promises require that every callable intent on that list, at the revision the compiler was built against, can be called from Python and has been run in the same test written in both d/BASIC and d/Python, on both its success and failure paths. Today all 191 callable intents can be called from Python, each checked by a test, and 86 of them have run in paired success tests, across math, widgets, graphics, files, hashing, sound and the network. It is not done, and the intent coverage page says which intents are still waiting.

Licences

The d/Python compiler and runtimes are written to ship under the MIT licence. The parser is RustPython's, version 0.4.0, under its MIT notice, which both the playground bundle and the macOS kit carry in third_party/. Python's own reference implementation and documentation are under the PSF License Version 2; d/Python's promises require that any grammar, code or tests reused from them keep their PSF notices and origin and are never relabelled MIT. The test programs on this site were written independently and are MIT. Python is a trademark of the Python Software Foundation; d/Python is not affiliated with or endorsed by the PSF. The fonts the playground draws with are under the SIL Open Font License.

Is this a toy?

It compiles a 130-line game with classes, changing lists and real input into 21 KB of bytecode that plays in a browser tab, and it stops and tells you, by name, about everything it cannot yet do. The honest description is an initial, tested implementation of a broader contract, which is also how the repository describes it.

What is next?

What d/Python promises sets the order: keep widening Python support against the compatibility table, get every intent running in a test and reach full parity with d/OS's features, and publish compatibility, size and responsiveness measurements. Floats, generator functions, a way to type text into a GUI field, type inference across a whole scope, and carrying a type tag with each value are the gaps the compatibility table names most often.