Add numpy ndarray support for LLM-generated Python

[trevorprater]

Summary

Adds numpy ndarray support to the Monty interpreter, enabling LLM-generated Python code that uses numpy to run in the sandbox.

• NdArray type (crates/monty/src/types/ndarray.rs): Core ndarray implementation with shape, dtype, and all standard methods (sum, mean, min, max, std, reshape, flatten, tolist, argmin, argmax, cumsum, round, clip, dot, astype, copy, sort, argsort, all, any) and attributes (shape, dtype, size, ndim, T)
• numpy module (crates/monty/src/modules/numpy.rs): 24+ functions including array creation (array, zeros, ones, arange, linspace), aggregation (sum, mean, min, max, std), element-wise math (abs, sqrt, log, exp, ceil, floor, log10, round, clip), and utilities (where, maximum, minimum, sort, unique, concatenate, cumsum, dot)
• Element-wise binary ops (binary.rs): +, -, *, /, //, %, ** for array+array, array+scalar, scalar+array
• Element-wise comparisons (compare.rs): ==, !=, >, <, >=, <= returning boolean ndarrays
• Unary negation for ndarrays
• Resource limits: Pre-allocation size checks on zeros, ones, arange, linspace to prevent memory exhaustion
• Plain list support: Element-wise functions (np.abs, np.sqrt, etc.) and aggregation functions (np.sum, np.mean, etc.) accept plain Python lists, matching real NumPy behavior

All behavior verified against CPython+numpy via ~200 assertion parity test.

Test plan

• 918 tests pass (make test-cases)
• numpy__parity.py — ~200 assertions verified against real CPython+numpy
• numpy__methods.py — ndarray methods and element-wise list tests
• numpy__arithmetic.py — element-wise binary ops
• numpy__array_creation.py — array, zeros, ones, arange, linspace
• numpy__comparison.py — element-wise comparisons
• numpy__math_functions.py — np.abs, sqrt, log, exp, etc.
• Resource limit checks prevent np.zeros(10**9) from allocating
• make lint-rs passes clean

[codspeed-hq]

Merging this PR will not alter performance

✅ 13 untouched benchmarks

---

_{Comparing trevorprater:feat/numpy-and-pandas (836898d) with main (95ab2ab)}

[codecov]

Codecov Report

❌ Patch coverage is 74.37965% with 413 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/monty/src/modules/numpy.rs	63.98%	120 Missing and 68 partials ⚠️
crates/monty/src/types/ndarray.rs	78.97%	105 Missing and 72 partials ⚠️
crates/monty/src/bytecode/vm/compare.rs	81.63%	14 Missing and 4 partials ⚠️
crates/monty/src/bytecode/vm/mod.rs	46.42%	15 Missing ⚠️
crates/monty/src/bytecode/vm/binary.rs	89.32%	4 Missing and 7 partials ⚠️
crates/monty/src/heap_data.rs	77.77%	1 Missing and 1 partial ⚠️
crates/monty/src/modules/mod.rs	75.00%	1 Missing ⚠️
crates/monty/src/object.rs	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[davidhewitt]

Thank you for this PR. As you note, it's absolutely massive. I can understand the use case however I'm also reluctant to add such a huge feature set to the codebase, it's also not a complete feature set of numpy / pandas so I would imagine that merging this will set precedent for:

• adding further numpy / pandas functionality not implmented in this PR
• adding further popular third-party modules

I worry this will quickly become unsustainable to maintain.

I wonder if there's a few different approaches to explore here:

• Do you think implementing the standard library array type will offer any value as a more constrained alternative?
• Similarly, is there value in merging the numpy portion without the pandas portion? (My gut tells me pandas is a much more complex project than numpy, however I could be wrong)
• As a more hand-wavy alternative, I wonder, is there a way to make it easier for users to customise their Monty with components that they want to add? I don't think we'll ever support loading external Python packages into Monty (?), however I could imagine that users implementing useful reusable pieces for Monty could add a lot of value for their own use cases.

[dheerapat]

I certainly would like to help here but my rust knowledge is next to nothing, I done my own sandbox project but it use pyodide which is different approach to monty here https://github.com/auto-medica-labs/vivarium

[samuelcolvin]

Hi thanks so much for this @trevorprater I agree with one of @davidhewitt's suggestions: we should add numpy to Monty, but not pandas.

Rationale:

• numpy is (AFAIK) in memory only, there's no debate about number writing to file or reading files (if there is some filesystem support, the fact I've never heard of it suggests agents won't want to use it)
• it's the only well known such library in the python ecosystem (unlike pandas where there's also polars)
• A really good pandas implementation would inevitably need to use a query engine (e.g. datafusion, polars or duckdb) for completeness and performance and that would enormously bloated the binary size - e.g. pydantic-monty is around 6MB today, while polars is from memory around 40MB

LMK what you think?

[trevorprater]

Thanks @samuelcolvin, that makes sense. I agree – numpy is a much cleaner fit for Monty’s scope. The pandas surface area is large and would inevitably pull toward needing a real query engine for completeness, which isn’t worth the binary bloat.

I’ll split the PR to numpy-only. Plan is:

1. Drop all pandas types (DataFrame, Series, GroupBy, string/datetime accessors) and associated tests

2. Untangle the shared plumbing in heap, heap_data, intern, value, and the VM binary/compare ops

3. Rebase on current main
   Should have the updated PR ready in the next few days.

@davidhewitt – apologies for the slow response, things have been hectic on my end. I really appreciate the thoughtful review and the suggestions around a plugin/extension mechanism (great idea).

[davidhewitt]

Great, no worries and no rush. FYI, I recently merged #265 which was a huge refactoring that'll likely hit this PR hard (but makes it MUCH easier to avoid copying data, satisfy borrow checker etc).

Happy to take pings if you need any comments about how to get this PR up-to-date with main for the numpy bindings.