Skip to content

Creating getters and setters for ndarray fields of structs #465

Open

Description

@iv461

I tried to write Python bindings for a struct containing ndarray type fields, but it does not compile: (rust-numpy v0.22.0)

use pyo3::prelude::*;
use pyo3::{pymodule, Bound, PyResult};
use numpy::ndarray::Array2;

#[pyclass(get_all, set_all)]
#[derive(Debug, Clone)]
pub struct Foo {
    vec: Array2<f64>,  
}

#[pymodule]
fn my_module(m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_class::<Foo>()?;
    Ok(())
}

I read the existing discussions (this and this) and they suggests writing getters and setters manually for each field, which is unsatisfactory.

This currently greatly limits the ability to make existing APIs that contain ndarrays available to Python: We can only use free functions but not structs or classmethods.

Why is this limitation ? Could it be solved by simply implementing the IntoPy<Py<PyAny>> and FromPyObject traits for ndarray ?
I see that this is done for smallvec's and having smallvec's as fields just works as expected.

Note also that this feature is present in C++'s pybind11 (the getters return a read-only array).

I would greatly appreciate the ability to bind ndarray fields and automatically provide getters and setters in Python. This would allow to fully bind an existing Rust API to Python.
Thanks a lot!

Activity

  1. davidhewitt commented on Oct 25, 2024

    @davidhewitt
    Member

    Because rust-numpy is a separate crate to PyO3, we can't directly implement for ndarray types due to the orphan rule. You could probably use a newtype in your struct e.g. (struct WrappedArray(Array2<f64>)) and implement IntoPy and FromPyObject yourself.

    It would be nice to have a cleaner solution for this in the future, though note that FromPyObject can be #[derive]-d and we will be adding #[derive(IntoPyObject)] (a new trait) in PyO3 0.23, which will make the newtype pretty easy.

  2. iv461 commented on Oct 25, 2024

    @iv461
    Author

    Thanks for the reply ! Then I'll use the workaround you mentioned, if it's currently not supported. I would be happy to see this supported in the future in the otherwise great Python-bindings library PyO3 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions