Repository navigation
[FEA]: Support exporting StridedMemoryView objects via DLPack #1438
Description
Description
Add support for exporting StridedMemoryView objects via the DLPack protocol.
Requested Features
Both the following protocols should be supported:
-
__dlpack__/__dlpack_device__- The standard Python DLPack protocol for interoperability with frameworks like NumPy, PyTorch, JAX, CuPy, etc. -
__c_dlpack_exchange_api__- The C-level DLPack exchange API for efficient zero-copy data sharing at the C/Cython level.
Motivation
Currently, StridedMemoryView can consume DLPack-compatible objects, but it cannot export itself as DLPack tensors. Adding export support would enable it to be seamlessly passed to any library that accepts DLPack inputs, improving interoperability across the Python data science ecosystem.
Additional Context
- DLPack spec: https://dmlc.github.io/dlpack/latest/
__c_dlpack_exchange_api__: https://dmlc.github.io/dlpack/latest/c_api.html#c.DLPackExchangeAPI- Related to the ongoing discussions around
StridedMemoryViewdesign (RFC: RemoveStridedMemoryView(to somewhere else)? #1371)
Activity
[-][FEA]: Support exporting `StridedMemoryView` and `Buffer` objects via DLPack[/-][+][FEA]: Support exporting `StridedMemoryView` objects via DLPack[/+]leofang commentedon Jan 8, 2026
Not re-exporting was done on purpose, because if a downstream consumer can accept DLPack already, why don't they just take the input arrays directly instead of trampolining through SMV?
kkraus14 commentedon Jan 9, 2026
It's not about trampolining, but with the new constructors for SMV, i.e.
from_buffer, there's more ways to construct an SMV and it's easier to use SMV conveniently as a return type in a downstream library and it would be nice to allow it to be passed around to other downstream libraries that haven't directly integrated with it.For something concrete, say someone wanted to use cuda.core to allocate some memory using a custom memory resource and run some numba-cuda kernels against that memory via SMVs and then pass the resulting SMVs over to something like PyTorch.