Is it possible to allow implicit conversion from Python lists to ndarray?

[Ahajha]

In porting some existing pybind11 code, it seems pybind11::array_t would accept a list (emphasis on seems, I did not write said code). I find myself having to provide a second version of everything taking an ndarray where I would also want to allow a list to be passed in. It's fine if this is the case, but is there a way of allowing such an implicit conversion?

[wjakob]

That's a bit more tricky in the case of nanobind because it has no dependence on NumPy for array_t. So it wouldn't be reasonable to first call np.array() and then convert from that. You would need a custom path that internally converts the list into a DLPack tensor and then passes that to the existing dlpack tensor interface.

I'm open to adding such a feature, but it's not high on my own priority list. Would you be interested in adding something like that?

[Ahajha]

I probably should have said something earlier, I am no longer working on the above project, and I unfortunately haven't had the time to work on this feature. So unless someone else is, I believe the answer is that nobody is working on this.

[eudoxos]

I might get to this, asking for general guidance. ndarray_import does currently (https://github.com/wjakob/nanobind/blob/62fc996018d9ea4d51af9c86cf008c2562b4eeab/src/nb_ndarray.cpp#L381-421)

1. check for dltensor capsule;
2. if that fails, check for known tensor packages (tensorflow, toch, jaxlib) and call their to_dlpack method;
3. if that fails, attempt dlpack_from_buffer_protocol

There would be an extra step added after that:

4. if that fails, attempt dlpack_from_sequence_protocol (to be implemented).

This new function would receive expected ndarray_config so that it can fail early when the input is not compatible (mismatched dimension, shape, unequal lengths of rows in a matrix, incompatible element type (int would be valid for integral dtypes, int || float for floating dtypes, complex for complex dtypes; int<0 would be refused for unsigned dtypes).

Like that?

[wjakob]

One question is how comprehensive dlpack_from_sequence_protocol should be. If the function expects a CUDA tensor, it is not realistic for nanobind to link to the CUDA library to move memory to the GPU to satisfy the requirements. The best we can do is to make a CPU tensor. And even that is quite complicated (e.g., figuring out the required type in multi-dimensional arrays, where maybe most of the entries are int and one of them is float....)

A less efficient but technically far simpler solution could be used in the case where the nb::ndarray<> type declaration is annotated with a given framework template parameter (e.g. nb::numpy). In that case the simplest solution would be to recursively call NumPy (or whatever framework was listed) to perform an implicit conversion from a sequence to the associated tensor type and then cast that using the available methods.

[eudoxos]

Thank you for the input. What I propose (simple, not to get overwhelmed):

1. restrict these conversions to numpy only (at first, at least) — I would assume GPU computations will rarely have small hand-written arrays like [1,2,3] as function parameters in the code (numpy is my use-case, so I might be biased).
2. enable the attempted conversion via #ifdef NPY_* (something, TBD), meaning nanobind will not have to deal with actually including numpy headers, as they have been included already.
3. Only attempt the conversion if the array is annotated as nb::numpy (or also if unannotated?).
4. Attempt to call PyArray_FromAny which will do all the heavylifting like nested sequences parsing, type conversions etc for us. Return either dlpack based on the array constructed (to be consistent with what is returned otherwise), or just numpy array as object already.
5. If the conversion fails, continue as usual.

[wjakob]

Including the NumPy headers is not an option (even if optional), so everything will need to go through the Python interface (which should be possible). To consider such a feature for inclusion in nanobind, it should also work on the other array frameworks.