[RFC]: DLPack based exchange of dtype and Device

Open

#972 opened on Sep 7, 2025 3 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 5/5
Estimated time: Over a week
Newbie friendliness: 35/100

Issue type: Feature
Clarity: Needs clarification
Activity status: Quiet
Tech stack: python
Domain: api

Research direction

No implementation files or tests are named. Start by reviewing the existing array API dtype and Device interfaces alongside DLPack's DLDataType and DLDevice definitions, then determine whether the proposed methods and from_dlpack support belong in scope. Done means the interface scope and specification are agreed.

Written by the indexing model from the issue text.

Description

API extension Needs Discussion RFC topic: Device Handling topic: DLPack

Background

As of now we have standard interface for exchanging tensors through DLPack. One minor but still useful thing is to also provide a mechanism for solutions. Motivating example

import numpy
import torch

# results in error
torch.empty((1, 2), dtype=numpy.float16)
# results in error
numpy.empty((1, 2), dtype=torch.float16)

It could be useful for the package.dtype and package.Device to be able to provide an interface for exchange such information. Given we already have DLDataType and DLDevice in dlpack, it might be helpful to bringup interfaces to transparently expose them. Such information can also be helpful for bindings to implement generic support for these types

Proposal

# defined in dtype
class dtype:
    def __dlpack_data_type__():
         """Return a tuple (code, bits, lanes) in DLDataType format 
         """

# defined in Device
class Device:
    def __dlpack_device__():
         """Return a tuple of (device_type, device_id) """

Then if desirable, the interface could implement something like

def empty(shape, dtype):
     if hasattr(dtype, "___dlpack_data_type__"):
           convert

There is also possibility of trying to run general value conversion. I do not think we have to update from_dlpack to also support these values, but there is an option to do so

def from_dlpack(src):
      if hasattr(src, "__dlpack__"):
            # this is an array
      if hasattr(src, "__dlpack_data_type__"):
            # this is a dtype
      if hasattr(src, "__dlpack_device__"):
            # this is a device

Dominant language: Python
Stars: 281
Forks: 52
PR merge metrics: No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

[essnmx] Fix typo in NXLauetof application definition Open

essnmx good first issue

Difficulty 1/5 Under an hour Newbie friendliness 95/100

scipp/ess#760 · Opened Sep 23, 2026
[Feature] 奇物选择添加优先级 Open

Difficulty 2/5 1-3 hours Newbie friendliness 65/100

syfoud/Simulated_Scepter#174 · Opened Sep 23, 2026
garak adapter grades a NaN detector score as PASS Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

Giskard-AI/giskard-oss#2840 · 1 comment · Opened Sep 23, 2026
A claim comment carrying the issue number is silently declined while the workflow reports success Open

area: repo bug perceived difficulty: 2

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

Nitjsefnie-Harness-Commons/daedalus#926 · Opened Sep 23, 2026
`IOCExtractor` always fails: `ioc_analyzer.build()` takes 1 argument but the agent dispatcher passes 2 Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

yeti-platform/yeti#1380 · Opened Sep 23, 2026

More Python issues