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

The monty interpreter enables the cpu-clock feature for native CPU accounting, which is Linux-only. Host-only users do not need this feature or its platform CPU dependencies. ExecutionClock::is_available() reports whether the current thread can read the selected clock.

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.

Execution time

Execution budgets charge bytecode and native builtins, excluding host suspension. They use ExecutionClock::Wall by default. Native callers can select ExecutionClock::Cpu with ResourceTracker::with_execution_clock. Subprocess hosts set PoolConfig::execution_clock once for the pool; CPU enforcement needs a local Linux subprocess worker, so remote (gRPC) setups enable it in the server's local pool. CPU mode samples the executing thread with a cache of up to 1 ms and reads exact execution boundaries. Unavailable or unusable counters use conservative elapsed time for that window; off Linux the counter is always unavailable, so check ExecutionClock::is_available() before selecting CPU mode directly. The OS controls counter accuracy and resolution. Snapshots preserve clock selection and recorded consumption. WebAssembly workers accept wall mode only.

License