d/Python playground guide

This page is a tour of the playground, the web page where you write and run d/Python without installing anything. You will learn what each part of the screen does, how to answer input(), how to share a program as a link, and where the limits are. The playground uses the real compiler, written in Rust, and the shared d/OS runtime, the program that runs your compiled code, both compiled to WebAssembly. It is not a JavaScript imitation. The compiled program file, .dbc, and its shared library files, .dbl, are handed to that runtime unchanged; a program you run here compiles to the same bytes the macOS command line would produce with its default optimization.

Your source stays in your browser; nothing is uploaded. The playground runs the runtime in its production setup with no providers attached (a provider is the part of the host that supplies files, or sound, or the network), which means no files, no network, no audio device and no pip. A program that declares it needs one of those is declined before it starts, with a message naming what is missing. MATH and the bounded SHA-256 executor are part of the shared runtime and work here.

Quick start

1. Open the playground.
2. Choose Tic Tac Toe from the Example menu.
3. Select Run, or press Cmd+Enter on macOS / Ctrl+Enter elsewhere.
4. Switch to the Graphics tab if the playground has not already, click the canvas, and click a square or press 1–9.
5. Edit the source and run it again. Download .py saves the current file.

The status line reads Compiling…, then Running, Waiting for input, Finished, Exited with status n, Refused, Stopped or Runtime unavailable.

Every Python code block in the guide has a ▶ Playground link. It opens a new playground tab and loads that exact sample into the editor. The source travels in the URL fragment, the part after #, which stays in the browser and is never sent with the web request. Samples marked as excerpts in the guide will produce a compiler message until you add the surrounding declarations the chapter describes.

The workbench

Source on the left is one Python file. Tab inserts four spaces. The position indicator shows the line and column. When the compiler finds a problem, its message appears under the editor with the line and column.

Console on the right shows the program's output. When a program calls input(), an answer row appears: type and press Enter, or choose End input to raise EOFError, or Cancel read to have d/OS cancel the read and stop the program with its standard cancellation message. What you type is never copied into the output. The last 65,535 bytes of output are kept; if a fast program prints more than the display can hold, the playground reports exactly where the lost beginning ends rather than hiding it.

Graphics shows a 320×200 window. Click it to give it the keyboard; key and pointer events reach the program as ordinary d/OS events. Enter, Escape, Backspace, Tab and the arrows have fixed codes; printable keys send their code point.

Stop ends the current run but keeps the worker; the next run starts fresh. Stop is an administrative action: it does not promise that a finally block or WINDOW_CLOSE ran.

Share links

Copy share link builds a URL whose fragment carries the whole program (#code=…, base64url, up to 256 KiB of source) and copies it to the clipboard. #src=/corpus/name.py loads a program from this site by path, #example=tictactoe loads a built-in example, and &run=1 runs it as soon as it loads. The corpus and examples pages use these.

Bounds

Bound	Value
Source	256 KiB
DBC image	512 KiB
Libraries	at most 8, 512 KiB each, 4 MiB total
One input line	65,535 bytes
Retained output	65,535 bytes
Scheduler	5,000-instruction slices, at most 32 per turn, a 6 ms allowance checked between steps

These are scheduling bounds, not hard deadlines: a large compile, a host allocation or a browser pause can exceed them. If the worker crashes, the page tells you, and a reload starts a new one.

What was tested

The tests for this bundle, run on 12 September 2026, exercised the real exported WebAssembly in Node. They covered NONE and ALL compilation, compiled output surviving later compiles, real library mounting, arbitrarily large integers and Unicode, prompt ordering and input arriving in chunks, the end of input staying in effect, exact cancellation, stale requests, missing libraries declined before any output, exact drawing records, and a d/BASIC program and a d/Python program sharing one runtime and one input path. In the browser, the checks covered Zoë 🐍 through input(), empty lines and the end of input, Stop on a graphics run and on an infinite loop, tic-tac-toe by pointer, retained widgets by pointer and Enter, two independent embeds, and a 390-pixel-wide viewport with no overflow. Physical IME input, matching behavior across browsers, and performance were not tested. This guide is not itself a claim about what runs; the corpus page is, for this exact bundle.