[dead]
Monty: A minimal, secure Python interpreter written in Rust for use by AI
111–120 of 179 posts
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#112I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…
This is very cool, but I'm having some trouble understanding the use cases. Is this mostly just for codemode where the MCP calls instead go through a Monty function call? Is it to do some quick maths or pre/post-processing to answer queries? Or maybe to implement CaMeL? It feels like the power of terminal agents is partly because they can access the network/filesystem, and so sandboxed containers are a natural extens…
It's right there in the README.
> Monty avoids the cost, latency, complexity and general faff of using full container based sandbox for running LLM generated code.
> Instead, it let's you safely run Python code written by an LLM embedded in your agent, with startup times measured in single digit microseconds not hundreds of milliseconds.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#113This feels like the time I was a Mercurial user before I moved to Git. Everyone was using git for reasons to me that seemed bandwagon-y, when Mercurial just had such a better UX and mental model to me. Now, everyone is writing agent `exec`s in Python, when I think TypeScript/JS is far better suited for the job (it was always fast + secure, not to mention more reliable and information dense b/c of typing). But I think…
Agreed, however AI adoption is finally putting pressure on CPython to have a JIT in the box, so there is that.
And on GPU side, the existing libraries provide DSL based JITs, thus for many scenarios the performance is not much different from C++.
Now NVidia is also on the game with the new tile based architecture, with first party support to write kernels in Python even.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#114This feels like the time I was a Mercurial user before I moved to Git. Everyone was using git for reasons to me that seemed bandwagon-y, when Mercurial just had such a better UX and mental model to me. Now, everyone is writing agent `exec`s in Python, when I think TypeScript/JS is far better suited for the job (it was always fast + secure, not to mention more reliable and information dense b/c of typing). But I think…
3 reasons why Python is much better than JS for this IMO. 1. Large built-in standard library (CSV, sqlite3, xml/json, zipfile). 2. In Python, whatever the LLM is likely to do will probably work. In JS, you have the Node / Deno split, far too many libraries that do the same thing (XMLHTTPRequest / Axios / fetch), many mutually-incompatible import syntaxes (E.G. compare tsx versus Node's native ts execution), and featu…
In Python you also have plenty of implementations to choose from, incidentally many of them have evem better performance than CPython.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#115Earlier quoted context omitted.
> In JS, you have the Node / Deno split, You do? Deno is maybe a single digit percentage of the market, just hyped tremendously. > E.G. compare tsx versus Node's native ts execution JSX/TSX, despite what React people might want you to believe, are not part of the language. > which only work if you pray three times on the day of the full moon. It only doesn't work in some contexts due to legacy reasons. Otherwise it's…
> JSX/TSX, despite what React people might want you to believe, are not part of the language. Similarly: TypeScript, despite what Node people might want you to believe, is not part of the JavaScript language.
People have to look into Typescript as a JavaScript linter and a babel replacement, nothing else.
In fact, the team has back pedaled into trying to make its own thing like in the early days.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#116I wish someone commanded their agent to write a Python "compiler" targeting WASM. I'm quite surprised there is still no such thing at this day and age...
Not sure if this is what you are looking for, but here is Python compiled to WASM: https://pyodide.org/en/stable/
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#117Earlier quoted context omitted.
TBF is the Python ecosystem any different? None and dict everywhere, requirements.txt without pinned versions... I'm not complaining either, as I wouldn't expect a unified typed experience in ecosystems where multiple competing type checkers and package managers have been introduced gradually. How could any library from the python3.4 era foresee dataclass es or the typing module? Such changes take time, and I favor a…
It was better because it had no silent errors, like 1+”1”. Far from perfect, the fact it raised exceptions and enforced the philosophy of “don’t ask for permission but forgiveness” makes the difference. IMHO It’s irrelevant it has a slightly better typesystem and runtime but that’s totally irrelevant nowadays. With AI doing mostly everything we should forget these past riddles. Now we all should be looking towards fa…
Conflating types in binary operations hasn't been an issue for me since I started using TS in 2016. Even before that, it was just the result of domain modeling done badly, and I think software engineers got burned enough for using dynamic type systems at scale... but that's a discussion to be had 10 years ago. We all moved on from that, or at least I hope we did.
> Now we all should be looking towards fail-safe systems, formal verification and domain modeling.
We were looking forward to these things since the term distributed computing has been coined, haven't we? Building fail-safe systems has always been the goal since long-running processes were a thing.
Despite any "past riddles", the more expressive the type system the better the domain modeling experience, and I'd guess formal methods would benefit immensely from a good type system. Is there any formal language that is usable as general-purpose programming language I don't know of? I only ever see formal methods used for the verification of distributed algorithms or permission logic, on the theorem proving side of things, but I have yet to see a single application written only in something like Lean[0] or LiquidHaskell[1]...
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#118I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…
> and rewrite their code to not use classes instead
Only if the training data has enough Python code that doesn't use classes.
(We're in luck that these things are trained on Stackoverflow code snippets.)
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#119I actually have no idea why this is needed. I want my models to have access to full libraries/sdks/apis and this is when they become actually useful.
I also want my models to be able to write typescript, python, c# etc, or any language and run it.
Having the model have access to a completely minimal version of python just seems like a waste of time.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#120I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…
I really don't understand the use-case here.
My models are writing code all day in 3/4 different languages, why would I want to:
a) Restrict them to Python
b) Restrict them to a cutdown, less-useful version of Python?
My models write me Typescript and C# and Python all day with zero issues. Why do I need this?