wrapping existing c++ ndarray classes without def_buffer function

[kaschau]

Is there documentation about providing a class binding for custom c++ ndarray types with their own pointer to shared data, ndims, shape, etc. into the new nb::ndarray<...> functionality? With pybind11 we created a

py::class_<MyType> _view ...

with a
_view.def_buffer(...)

and a lamba to return the py::buffer_info.

Is there a way to provide python with the nb::ndarray information in a similar manner, while still keeping the original c++ type of the class instance? (For context I am trying to create bindings for Kokkos views to be passed back and forth between python and c++ functions expecting Kokkos views as inputs).

[kaschau]

I've been working this all day and of course the second I post I find a solution. One can define the __array__ method and return an nb::ndarray<> using the data from the c++ class like ndims, etc. So it won't outright return an np.ndarray, but you can then wrap the objects with np.array(view) and it will find everything it needs. Though I would be interested to hear if there are better ways of doing thing.

[wjakob]

This sounds like a good solution to me (and I agree that the nanobind documentation could be more explicit about this way of exposing NumPy access to a data structure -- PRs are welcomed in case you are willing to contribute this tot he documentation). Regarding this point:

So it won't outright return an np.ndarray, but you can then wrap the objects with np.array(view) and it will find everything it needs. Though I would be interested to hear if there are better ways of doing thing.

That would have been the same with pybind11-style .def_buffer, right?

[kaschau]

yes you are correct, this actually turned out to be suitable for us as the pybind11 version already wrapped with np.array() so it was an easy solution.

I do not think what I was originally looking for is possible, as it would require the treatment of the same object as a np.array type on the python side, but when passed to a bound c++ function, it needs to be a Kokkos::view type. So keeping two separate python variables, one of np.array(view) and one of view is a decent trade-off.