Crate monty_type_checking 

monty-type-checking

Type checking for Monty, powered by ty.

Monty supports full modern Python type hints. This crate embeds ty’s semantic analysis (Astral’s ty_python_semantic engine — the same one behind the ty type checker) and checks code against monty-typeshed: a trimmed typeshed describing the stdlib subset Monty actually implements. Code that uses unsupported stdlib surface is therefore flagged before it runs rather than failing at runtime.

It backs monty --type-check in the CLI and the type_check option on sessions in the pydantic-monty and @pydantic/monty packages.

Usage

use monty_type_checking::{SourceFile, TypeChecker};
use monty_types::TypeCheckingConfig;

let mut checker = TypeChecker::default();
let source = SourceFile::new("x: int = 'not an int'", "main.py");
let diagnostics = checker.run(&source, None, TypeCheckingConfig::default()).unwrap();
// `Some(...)` means typing errors were found; `None` means the code is clean
assert!(diagnostics.is_some());

The second argument is an optional stubs file declaring names the host will provide at runtime (external functions, inputs). The stubs are written alongside the source and a from <stubs> import * line is injected, so checked code can reference host functions without defining them — diagnostic line numbers are adjusted back to the original source.

TypeCheckingConfig picks the output format (ty’s full, concise, json, github, … renderings) and whether to use ANSI colour. It is passed to run rather than applied to the result because TypeCheckingDiagnostics borrows the checker — ty’s diagnostics resolve their spans against the database that produced them, so anything that outlives the checker (notably anything crossing a process boundary) has to keep the rendered string.

Reusing a checker

A TypeChecker owns one in-memory salsa database, so reusing it across checks avoids rebuilding typeshed-derived semantic state every time — which is what makes per-feed checking in a REPL session affordable. Files written by a previous run stay in the database (rewritten in place when the path repeats), so call reset before checking an unrelated session’s code: it scrubs every file written so far, including the directories they created. TypeChecker is not Sync; concurrent checks each need their own.

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.
• 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. this crate
• monty-typeshed — the trimmed typeshed stubs describing the stdlib subset Monty implements.
• monty-macros — the proc macros behind monty’s argument parsing.

Structs

SourceFile

Definition of a source file.

TypeChecker

TypeCheckingDiagnostics

The diagnostics of one failed type check, rendered on Display.