Interop

Python Backend

What generated Python provides, how to build it, and where the host boundary begins.

Python is a generated deployment target, not embedded syntax or a second Topaz runtime model. The checker resolves the complete Topaz program first; the backend then writes Python plus the shipped support module needed to run the accepted program.

Contract and components

A package build produces program.py and topaz_py_rt.py. The generated program requires Python 3.11 or newer, but it does not require the Topaz compiler or source package at runtime. Package-mode filesystem capabilities, arguments, standard input, output, errors, and exit status remain explicit parts of the generated product.

Workflow

Keep application logic and its public module API in checked Topaz. Run the reference path and package tests first, build the Python target, then exercise the generated product with the same declared inputs and observables. Ship both generated files together and treat any surrounding Python launcher or service as separately owned host code.

topaz check --root . --locked
topaz test --root . --locked
topaz build --target python --root . --locked --out-dir python-out
python3 python-out/program.py

Boundaries and limitations

Python imports, decorators, exceptions, generators, annotations, and package APIs are not Topaz syntax. Generated source is a deployment artifact rather than a stable handwritten extension point. The compiler rejects a shape when the selected backend cannot preserve its checked behavior; successful code generation is not a promise that arbitrary Python libraries or exceptions are available from .tpz source.