paleolimbot commented on issue #38325: URL: https://github.com/apache/arrow/issues/38325#issuecomment-2047504194
Only mentioning this because I just ran across it, but dlpack apparently uses a consumer-provided version: > Starting Python array API standard v2023, a new max_version argument is added to __dlpack__ for the consumer to signal the producer the maximal supported DLPack version. For what it's worth, I think a producer-defined `__arrow_c_api_version__` is the cleanest possible solution: it's very easy to implement for a producer, and very easy for a consumer to generate an informative error (or adjust calling code accordingly). The other ways are fine too, but it seems like they are possibly inventing a brand new way to deal with Python API evolution and I am not sure there is sufficient evidence based on the experience of the array API or dlpack that there is a need to invent a brand new way to do this. > When specified, it accepts integer values corresponding to ArrowDeviceType from the ABI Would the request also have to specify the `device_id`? > Because that can then be covered with the more explicit `__arrow_c_device_array__(requested_device=kCPU)` From a CPU calling library perspective, I would prefer to only have to deal with `__arrow_c_array__()`, or possibly `__arrow_c_array__(copy=True/False/None)` in some future version of that method (since a cross-device copy is not the only type of copy a caller might want to prevent). Adding `requested_device` is fine too and I'm in favour of all outcomes that let this interface start being implemented, I am just worried that adding an argument before any implementations exist is going to mean that we risk having to change its interpretation or remove it (defeating the purpose of adding it early). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
