It's a great way to expose Python bindings because it "feels" Pythonic. Most users run pip install deltalake and are completely unaware that the backend is implemented in Rust.
This is quite a different user experience than Python bindings for Java backends exposed via py4j. The py4j interfaces have the Java feel and require Java to be installed, which most Python users don't like.
I think Python & Rust can become great pairs, especially in the data processing field.
Also, once you play with it more than 30m, you quickly realize that struct attributes are copied all over the place... which is not only slow, but more sadly any mutable function on an attribute will just silently modify a temporary copy...
From my experience the trickiest bit of getting python extensions to work (i.e. not segfault) is dealing with the lifetimes of the objects in the wrapped library. If python owns the object you’re golden, if it borrows a reference then things get real complicated real fast. It usually takes a lot longer to get the ownership model correct than doing the grunt work of wrapping the library — unless you own the lib and make it python friendly it’s usually a case of “do what you can with what you were given”.
Blender’s python API is full of cases where the python object can’t be trusted to be valid if you do anything with the underlying container and it is super easy to crash the whole program doing something that should Just Work™.
Wondering how rust would deal with the cross-domain model where nothing can be guaranteed once python gets its dirty little paws on the pointer?
The lib.rs is all of 125 SLOC (and about half of that is owing to the handling of `attribute_filter` which is pretty demanding on the glue layer: https://github.com/messense/nh3/commit/72be3e6728b7ceb9185e7...).
