monty-types

Shared boundary types for Monty, the Python sandbox — the owned, heap-free data types that cross between the sandbox and the hosts that embed it, with no interpreter implementation.

What's here

• MontyObject / MontyType — Python values and their types at the host boundary, including the datetime family (MontyDate, MontyDateTime, MontyTimeDelta, MontyTimeZone) and MontyFileHandle.
• ObjectRef — a borrowed value, with typed accessors (as_int, as_str, items, pairs). MontyObject::as_ref() borrows a value for inspection.
• CallArgs / NamedValues — the arguments or inputs of one message. Their builders accept MontyObject values; their iterators return borrowed values. Both carriers and the MontyObject / ObjectRef types keep their fields private.
• unstable — graph representation APIs for bindings and transport adapters, with no API compatibility guarantee. They may change or disappear in any release; prefer value constructors and typed accessors when possible.
• MontyException / ExcType — exceptions with tracebacks (StackFrame, CodeLoc) and structured payloads (ExcData).
• OsFunctionCall — the typed OS-call payloads sandboxed code suspends with (file reads/writes, open(), os.getenv, ...), plus the stat_result builders hosts use to answer them.
• MontyPath preserves OS-call paths for validation; normalize_virtual_path provides the lexical POSIX normalization shared by the interpreter, mounts, and OsFunctionCall::to_args() callbacks. It borrows canonical paths and resolves relative inputs from /. Validate NUL bytes and path limits before calling it; it does not confine filesystem access.
• ResourceTracker / ResourceLimits — the resource tracker the interpreter uses to enforce time/memory/recursion limits, plus the max_suspensions budget hosts enforce themselves.
• PrintStream / PrintWriter / CollectedStreams — print() output capture, and the labelled buffer behind PrintWriter::CollectStreams.
• CompileOptions, ExtFunctionResult, NameLookupResult, FileMode, and the CPython-compatible formatting helpers behind their repr()s.

Who should depend on it

Host-side crates that need these types without linking the interpreter — monty-fs (which services OsFunctionCalls locally via MountTable::handle_os_call), monty-pool (which talks to Monty workers over the wire), the pydantic-monty-client Python bindings and the @pydantic/monty JS bindings — depend on this crate instead of monty, so their binaries never link the interpreter itself. Only worker-side crates (monty-runtime, monty-wasm-runtime, and monty-proto with its worker feature) link monty.

use monty_types::MontyObject;

let value = MontyObject::list([MontyObject::int(1), MontyObject::string("x".to_owned())]);
assert_eq!(value.py_repr(), "[1, 'x']");

Monty crates

• monty — the core interpreter: Python parser, bytecode VM, and sandbox.
• monty-types — the shared boundary data types (values, exceptions, OS calls, resource limits) hosts use without linking the interpreter. this crate
• monty-fs — host-side filesystem mounts: maps virtual sandbox paths to real host directories.
• monty-runtime — the monty binary: REPL, file runner, and subprocess worker mode.
• monty-pool — an elastic pool of crash-isolated monty worker subprocesses.
• monty-proto — the protobuf wire protocol spoken between pool parents and workers.
• monty-type-checking — type checking of sandboxed code, powered by ty.
• monty-typeshed — the trimmed typeshed stubs describing the stdlib subset Monty implements.
• monty-macros — the proc macros behind monty's argument parsing.

License

MIT