Thanks Hameer, looks like a good start.

Of the points @seberg brought up on the issue, adding a version attribute seems the most important - because checking for version will be needed before any backwards-incompatible change (such as adding an extra field) can be done. I asked about it on dmlc/dlpack#34, and the suggestion was to add it as an attribute on the PyCapsule. Could you look into doing that?

Could you look into doing that?

Sure -- I commented there instead of here, so more of the relevant parties can see it.

This name should be some standardized DLPack name? Or is this intentional for now to keep it effectively private right now?

Well, we have to be able to delete it to free the memory, but maybe we need some state as well, to ensure that we don't delete it twice if the consumer already deletes it without deleting the capsule (might be good for non-reference counted Python also?).

I thought I read that there was some capsule renaming involved (to signal that its "invalid" after deletion). I guess setting the data to NULL or so would be just as well. (If this is standardized, do that. If not setting data to NULL to guard against deleting twice? Once from python once from the consumer.)

There's a standardized name, see data-apis/array-api#186. I have modified the PR accordingly.

We need to also check for the DType being native. I assume unaligned is OK?

Unaligned is OK, see #19013 (comment). How does one check for native dtypes?

Maybe we should just explicitly list them? We cannot include longdouble here, since the C99 standard doesn't specify it (I am not even sure IBM double-double is strictly standard conform). And I assume Float in DLPack means IEEE compatible float format of defined size. float16, float32, and float64 are fine, for the others maybe DLPack should add an extended float field or so, if we want it?

I just don't see longdoublel to be much good, considering its already system dependend on the CPU alone...

Can we verify this?

Can we verify this?

Ignore, it does mean IEEE float. Does np.float80 or np.float128 not respect the IEEE convention? In that case, it makes sense to limit both complex and floats. Otherwise, the receiving library can deny the incoming datatype by reading the bits field.

np.float80 etc are all just aliases for np.longdouble based on what C produces for sizeof(long double)

I guess if longdouble is 64bit, you can be sure its just double. That we could check for if we want. There are a couple of macros in numpy/core/src/common/npy_fpmath.h such as HAVE_LDOUBLE_IEEE_QUAD_BE. I don't know how well they work/are tested, but I guess technically you could check for that to catch the rare cases where we have proper quad precision.

Technically, most current hardware uses something like 80bit (IEEE?) stored as 96bit or 128bit. But DLPack can't describe it (its an old thing that our float128 should relaly be float128_80 or something else than float128...). Something, that will eventually be important if quad precision becomes a real thing.

How does one check for native dtypes?

You can use PyDataType_ISNOTSWAPPED.

I will put this in once the tests pass, but will then open a few issues about dlpack, with pretty harmless bugs or general followups. The release notes get reviewed before the release anyway.

Thanks everyone and especially Matti for doing the follow-ups.

🎉 thanks @mattip, @hameerabbasi, @seberg, @leofang & all other reviewers!

Silly question: Can someone remind me why we renamed it to np._from_dlpack() (prefixed with an underscore)?

This was pushed in a ~1 week before branching with not quite settled things in dlpack itself (as I remember). Adding the underscore was the way to not having to discuss all of that in a short time frame.

I see, thanks for the context @seberg. Sounds like a decision made offline (which I am fine with). Is there any plan to make it a public API (by removing the underscore)?

Yes, we can discuss this obviously. It may have been discussed in a meeting, in which case it is publically noted in the numpy/archive repo. I feel the PR had the underscore initially, because the first step was to make it available for the _array_api namespace.

The only mention of dlpack in the docs is in the release notes, so maybe we could discuss making it public together with some documentation.

Thanks, guys. I created an issue to track this change: #20743.

Does numpy._from_dlpack support construction from a raw capsule?

E.g. PyTorch supports both raw capsule input and an object having __dlpack__ instance method:
https://pytorch.org/docs/stable/generated/torch.from_dlpack.html:
If ext_tensor is a tensor (or ndarray) object, it must support the __dlpack__ protocol (i.e., have a ext_tensor.__dlpack__ method). Otherwise ext_tensor may be a DLPack capsule, which is an opaque PyCapsule instance, typically produced by a to_dlpack function or method.

Original issue:

• Import DLPack tensors directly into NumPy (without going via PyTorch or TF) dmlc/dlpack#55

My original DLpack python/numpy bindings:

• https://github.com/vadimkantorov/pydlpack/blob/master/dlpack.py

@vadimkantorov If understand correctly, direct capsules are tricky and shouldn't be passed around by library consumers.

The current recommendation is that libraries should only support other array objects in from_dlpack.

@hameerabbasi PyTorch's https://pytorch.org/docs/stable/dlpack.html#torch.utils.dlpack.to_dlpack actually returns an opaque Capsule object... What would be nice is having an example of producing a DLPack struct from C function (via ctypes) or PyCapsule from PyTorch - and then consuming it from NumPy - to showcase the interop situations

I did hacks for some usecases like this in https://github.com/vadimkantorov/pydlpack and https://github.com/vadimkantorov/readaudio

@vadimkantorov torch.utils.dlpack.to_dlpack is legacy, just don't use it. PyTorch tensors have a __dlpack__ method, so you can simply use np.from_dlpack(a_tensor).

The usecase where DLPack is used for marshalling an array from C land (function can be bound with DLPack) into a NumPy tensor is also very useful: plain C functions with DLPack structures is much simpler to compile / manage than building torch/numpy extensions

In my example I used DLPack-producing C functions doing audio decoding, and then ingesting such a DLPack ctypes-bound structure in NumPy. Does NumPy also provide such ctypes binding types for DLPack structures?

It doesn't. But if you already have a raw capsule, it should be quite easy to wrap it in a thin pure Python class with __dlpack__ and __dlpack_device__ methods - that should be all you need.

For some reason (maybe inspired with original PyTorch support), NVidia's Triton Inference Server API for to_dlpack also returns capsule objects:
https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/python_backend/README.html#interoperability-and-gpu-support