Why does ndarray_wrap tend to copy?

[WKarel]

Given an ndarray_handle and numpy as framework, ndarray_wrap creates a new nb_ndarray instance (that shares the data of the ndarray_handle), and calls numpy.array(nb_ndarray), which makes NumPy request a buffer from the nb_ndarray, again sharing the data. All reference counting seems fine, and no copying of data is involved if e.g. none is passed as return value policy.

With the defaults passed by nb::cast (copy/move), the data IS copied, however. What is the reason for that, given that ndarray_handle et al. have all means to share data? Why does ndarray_wrap consider a return value policy at all? This seems to contradict the documentation saying "A return value policy is unnecessary when the type itself clarifies ownership...".

Thanks!

[wjakob]

For historical context: Initially, nanobind would make a DLPack capsule and then convert that into an nd-array of choice (NumPy, PyTorch, etc.). However, the NumPy <-> DLpack interface was found to be insufficient since non-brand-new numpy versions didn't support it, so I added an extra indirect path via an nb_ndarray exposing the buffer protocol. Later, people noticed that the NumPy <-> DLPack interface is too limited even on brand-new NumPy versions, so I entirely switched it over to the buffer protocol and disabled the DLPack code path for NumPy.

Can you explain the problem you are experiencing with the return value policies? It may be helpful to see an actual example.

[wjakob]

Can you let me know if this looks reasonable to you?

[WKarel]

My use case works now, and so I'm happy, thanks. Still, a dedicated copy-method would seem cleaner to me from an application's point of view, with type_caster treating ndarray like an intrusive pointer for detail::ndarray_handle. But maybe I miss an obstacle in there.

Besides, I have posted 3 comments for the commits you mentioned above.

[wjakob]

treating ndarray like an intrusive pointer for detail::ndarray_handle.

Isn't that what it does already? (including, e.g., the necessary reference counting)

Copying the array is quite entangled with actual type casting step. For many array types (e.g. a CUDA or hypothetical ROCm array) we don't have access (at least directly in nanobind) to the API that would let us copy the array, and we need to ask the framework to do this when converting from an abstract device pointer to a Python object. Hence the reason to package this up as a return value policy

[wjakob]

Thanks for the three comments, I incorporated them.

[WKarel]

treating ndarray like an intrusive pointer for detail::ndarray_handle.

Isn't that what it does already? (including, e.g., the necessary reference counting)

I meant the behaviour that e.g. type_caster<std::shared_ptr>::from_cpp has: it simply ignores the passed return value policy, and will never copy the pointee. But never mind, I see that the implementation is simpler this way.