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 53 rows and none is marked complete. Generator functions, async, descriptors, metaclasses, multiple inheritance, custom operators on your own classes, 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 "abc".upper()?

Because that string method is not implemented yet, and d/Python's promises say an unsupported feature must get a clear message or a defined exception, never a program that quietly does something slightly different. The compiler stops at the line and column and names the method. The compatibility table records every such gap with the reason; string methods, % formatting and generator functions are the ones a Python programmer meets first. Numbers, by contrast, are complete enough for daily work: integers of any size, floats that behave exactly like Python's, round, format and complex numbers are all checked against the reference CPython build.

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?

From the releases page: a universal macOS kit (Apple silicon and Intel), Linux x86-64 and Windows x86-64 kits, and the browser bundle (the compiler and runtime as WebAssembly, for embedding in your own site). Each kit is a folder you can move anywhere, with the dpython command line (check, build, run, inspect, trace, bindings, package), the dbasic window host, compiled examples, the guides and the compatibility tables; The macOS Kit describes the layout. The window host is cross-platform (winit and wgpu), so window programs open a real window on macOS, Linux and Windows with a display. Copy and paste and drag and drop are wired to macOS for now; terminal input() works on macOS and Linux but not yet on Windows. The kits are pre-release: they are signed by their manifest's SHA-256 list, not yet notarized.

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?

They are first-class desktops, not an afterthought. The compiler, the runtime and the native window host are portable Rust; the window layer is the cross-platform winit and wgpu, so console programs and window programs both run on Linux and Windows with a display, and the browser build runs anywhere a browser does. The command-line suites pass on both (test runs of 12 September 2026). What is still macOS-only is narrower than a whole platform: the copy/paste and drag native bridge, and, on Windows only, the terminal path behind input() (on Linux, 65 of the 66 test programs pass; the one that calls input() on Windows is declined and says why, rather than faked).

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 206 callable intents can be called from Python, each checked by a test, and 121 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 toolchain is free to download and use, including commercially, under the Kall Innovations toolchain licence. What you build with it is yours: no royalty, no attribution, no licence terms attach to your programs, and you may embed the unmodified browser bundle in your own site. The toolchain itself is not open source. 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.