Skip to content

The macOS kit

The macOS kit is a folder you can build yourself that contains everything needed to compile and run d/Python programs natively on a Mac. This page tells you what is in it, how to run the examples, what the console window does, how the kit is checked, and what it is not.

The kit is produced by d/Python's own build script from one fixed snapshot of the source. Building it needs the Rust toolchain, the Xcode Command Line Tools and Python 3.9 or later. It is built for the architecture of the machine that builds it, never overwrites an existing output, and installs nothing system-wide. You can move the folder anywhere and it keeps working. A signed, notarized public download is planned; until it exists, the kit is how developers with access to the source run d/Python natively.

What is in it

  • bin/dpython, the compiler and console runner, and beside it bin/dbasic, the native graphics host that opens windows. Keep the two together; DPYTHON_HOST overrides how the first finds the second.
  • examples/*.py, the example sources, and programs/*.dbc, seven of them compiled, with the shared library files, .dbl, they need in programs/lib/.
  • console/console.dbc, a console application written in d/BASIC, d/OS's other language, which shares the same runtime, that provides windowed line input, with a note saying where its source is.
  • compatibility/, the compatibility tables; third_party/, the RustPython notice; manifest.json and verification.json.
./bin/dpython run programs/hello.dbc
./bin/dpython run programs/fibonacci.dbc
./bin/dpython run programs/console_input.dbc
./bin/dpython run programs/retained_window.dbc
./bin/dpython run programs/tictactoe.dbc
./bin/dpython run --console-window console/console.dbc programs/console_input.dbc
./bin/dpython check examples/hello.py
./bin/dpython build examples/fibonacci.py -o my-program/fibonacci.dbc

The window examples open a native window on their own. Tic-tac-toe takes clicks or the keys 1 to 9, with R to reset; the retained-widgets example responds to its button, to Space and Enter, and to resizing.

The console window

--console-window runs a console program alongside a separate console application written in d/BASIC. Both run as compiled programs under the shared runtime; the console shows your program's output and supplies each line of input through the same service Python's input() uses. Its controls are Submit (send one line, including an empty one), End input (end of input; input() raises EOFError), Cancel read (the read is declined with d/OS's cancellation message) and Stop program (ends the program, keeps the transcript). Closing the window gives the console 250 ms to finish its CLOSE cleanup, then stops whatever is left. This first version accepts 4,096 UTF-8 bytes per line and shows five rows. It is one console window for a program that has no window of its own, not a text field for an arbitrary graphical program, and it declines --file-mount before launch.

Relocation checks

Every build copies the kit to a temporary path with spaces in it, switches to an unrelated working directory with only the system's PATH, clears the host override, rebuilds all seven examples and compares the program and library bytes, checks each program's declared kind, compares console output from running the source and the compiled file, feeds the input example a fixed line, proves that window programs find and start the real sibling host (by asking for a permission the host must decline), and starts the console-window mode expecting it to decline a file mount. The kit of 12 September 2026 passes all of these checks, plus a set of terminal checks (normal exit, SIGINT, SIGTERM, SIGKILL, blocking and non-blocking) that leave the terminal's settings unchanged.

python3 verify_macos.py --verify-only .

repeats the checks inside a moved kit without changing it. The verifier also declines any binary that links to dynamic libraries outside macOS's system locations.

What it is not

The kit is a local developer kit for the part of Python that d/Python supports today, built for one architecture. It does not establish full Python compatibility, support for PyPI packages or C extensions, complete parity with d/OS, that it will run on another Mac or an older macOS, or that a signed and notarized public release exists. Window drawing, input, resizing and closing still need to be checked by hand on the machine where the kit will run.