Do we need from_dlpack when DLPack is supported by asarray?

I guess one possible advantage of from_dlpack() is that it’s more explicit? If that’s desired, then perhaps we should add other explicit constructors like from_buffer(). Otherwise, it seems redundant with the generic asarray(), and I would lean towards removing it.

[rgommers]

Would it be better, then, to remove both DLPack and buffer protocol supports from asarray(), so it is more focused and has a separate responsibility from from_dlpack()?

I’m not sure, maybe. I’m fine removing just DLPack as well, or leaving as is, or removing both. I think idiomatic code would use:

• from_dlpack for standard-compliant objects
• asarray for converting scalars or sequences
• preferably nothing else (because nothing else will have universal support)

It’s not great in a standard to have to deal with optional other protocols that are hard to test for. Saying the buffer protocol must/may be supported is not ideal in both cases. And __array_interface__ or __cuda_array_interface__ the same. I’d lean towards an explicit “may” if we want to do anything, not a “must”.

from the perspective of CUDA/ROCm whatever can be done using DLPack (without the Python methods) can also be done using the buffer protocol,

I’m not sure what this means, since the buffer protocol does not support GPUs. Do you mean __cuda_array_interface__ maybe?

[leofang]

from_dlpack is the one function that one should be using when converting one kind of array into another where you know both support the array API standard. It’s more explicit (signalling intent to the reader of code matters), reliable and fast.

I’d much rather remove buffer protocol support from asarray.

Would it be better, then, to remove both DLPack and buffer protocol supports from asarray(), so it is more focused and has a separate responsibility from from_dlpack()?