// the find
PyO3/rust-numpy
PyO3-based Rust bindings of the NumPy C-API
rust-numpy lets you write Rust extension modules that take and return NumPy arrays, bridging PyO3 and the NumPy C-API. The target audience is people building Python scientific computing extensions who want Rust's speed without giving up NumPy interop. It sits under the PyO3 umbrella, so if you're already using PyO3, this is the obvious path.
The borrow-checker integration is genuinely well thought out — PyReadonlyArray and PyReadwriteArray enforce at compile time that you don't hold conflicting borrows across the Python/Rust boundary, catching a class of bugs that would be silent UB in C extensions. The ndarray re-export and direct view conversions (as_array(), as_array_mut()) mean you don't write any unsafe glue for the common case. The parallel example with rayon is useful: it shows how to release the GIL correctly while doing parallel array work, which trips up most people the first time. CI covers multiple Python versions and numpy versions, so the compatibility story is actually tested rather than aspirational.
The ndarray version range problem described in the README is a real footgun — depending on both 0.15 and 0.16 silently is exactly the kind of thing that causes mysterious type mismatch errors when you try to pass arrays between crates, and the fix requires manual cargo update incantations. String array support exists but is clearly second-class; structured dtypes and record arrays are mostly out of scope, so if your Python code uses anything beyond numeric types you'll be writing unsafe npyffi calls yourself. The unsafe surface is still larger than it looks — as_array_mut() is explicitly unsafe and the borrow model only protects you when you go through the typed wrappers, not when you drop to raw C-API calls in npyffi. 1,378 stars for something this fundamental suggests it's still more of an expert tool than a mainstream one, and the documentation assumes you already understand both PyO3 and ndarray fairly well.