Live data from Hacker News

Monty: A minimal, secure Python interpreter written in Rust for use by AI

github.com

21–30 of 179 posts

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#21
post #3

I'm of the mind that it will be better to construct more strict/structured languages for AI use than to reuse existing ones. My reasoning is 1) AIs can comprehend specs easily, especially if simple, 2) it is only valuable to "meet developers where they are" if really needing the developers' history/experience which I'd argue LLMs don't need as much (or only need because lang is so flexible/loose), and 3) human langua…

I think the hard part about that is you first have to train the model on a BUTT TON of that new language, because that's the only way they "learn" anything. They already know a lot of Python, so telling them to write restricted and sandboxed Python ("you can only call _these_ functions") is a lot easier.

But I'd be interested to see what you come up with.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#22
I don't quite understand the purpose. Yes, it's clearly stated, but, what do you mean "a reasonable subset of Python code" while "cannot use the standard library"? 99.9% of Python I write for anything ever uses standard library and then some (requests?). What do you expect your LLM-agent to write without that? A pseudo-code sorting algorithm sketch? Why would you even want to run that?

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#23
Maybe a dumb question, but couldn't you use seccomp to limit/deny the amount of syscalls the Python interpreter has access to? For example, if you don't want it messing with your host filesystem, you could just deny it from using any filesystem related system calls? What is the benefit of using a completely separate interpreter?

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#24

It is absurd for any user to use a half baked Python interpreter, also one that will always majorly lag behind CPython in its support. I advise sandboxing CPython instead using OS features.

Python already has a lot of half-baked (all the way up to nearly-fully-baked) interpreters, what's one more?

https://en.wikipedia.org/wiki/List_of_Python_software#Python...

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#25
post #19
post #9

If we’re going to have LLMs write the code, why not something more performant? Like pages and pages of Java maybe?

this is pretty performant for short scripts if you measure time "from code to rust" which can be as low as 1us. Of course it's slow for complex numerical calculations, but that's the primary usecase. I think the consensus is that LLMs are very good at writing python and ts/js, generally not quite as good at writing other languages, at least in one shot. So there's an advantage to using python/js/ts.

Seems like we should fix the LLMs instead of bending over backwards no?

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#26
post #22

I don't quite understand the purpose. Yes, it's clearly stated, but, what do you mean "a reasonable subset of Python code" while "cannot use the standard library"? 99.9% of Python I write for anything ever uses standard library and then some (requests?). What do you expect your LLM-agent to write without that? A pseudo-code sorting algorithm sketch? Why would you even want to run that?

They plan to use to for "Code Mode" which mean the LLM will use this to run Python code that it writes to run tools instead of having to load the tools up front into the LLM context window.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#28
post #22

I don't quite understand the purpose. Yes, it's clearly stated, but, what do you mean "a reasonable subset of Python code" while "cannot use the standard library"? 99.9% of Python I write for anything ever uses standard library and then some (requests?). What do you expect your LLM-agent to write without that? A pseudo-code sorting algorithm sketch? Why would you even want to run that?

It's pydantic, they're verifying types and syntax, those don't require the stdlib. Type hints, syntax checks, likely logical issues,etc.. static type checking is good with that, but LLMs can take to the next level where they analyze the intended data flow and find logical bugs, or good syntax and typing but not the intended syntax.

For example, incorrect levels of indentation. Let me use dots instead of space because of HN formatting:

for key,val in mydict.items():

..if key == "operation":

....logging.info("Executing operation %s",val)

..if val == "drop_table":

....self.drop_table()

This uses good syntax, and I the logging part is not in the stdlib, so I assume it would ignore it or replace it with dummy code? That shouldn't prevent it from analyzing that loop and determining that the second if-block was intended to be under the first, and the way it is written now, the key check isn't done.

In other words, if you don't want to do validate proper stdlib/module usage, but proper __Python__ usage, this makes sense. Although I'm speculating on exactly what they're trying to do.

EDIT: I think I my speculation was wrong, it looks like they might have developed this to write code for pydantic-ai: https://github.com/pydantic/pydantic-ai , i'll leave the comment above as-is though, since I think it would still be cool to have that capability in pydantic.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#29
This is a really interesting take on the sandboxing problem. This reminds me of an experiment I worked on a while back (https://github.com/imfing/jsrun), which embedded V8 into Python to allow running JavaScript with tightly controlled access to the host environment. Similar in goal to run untrusted code in Python.

I’m especially curious about where the Pydantic team wants to take Monty. The minimal-interpreter approach feels like a good starting point for AI workloads, but the long tail of Python semantics is brutal. There is a trade-off between keeping the surface area small (for security and predictability) and providing sufficient language capabilities to handle non-trivial snippets that LLMs generate to do complex tasks

Post reply on HN