kkraus14 commented on issue #38325:
URL: https://github.com/apache/arrow/issues/38325#issuecomment-2046321496
> Versioning of or tracking of capabilities in the C Data Interface itself
is out of scope for this discussion, I would say (it's an interesting topic and
has come up before, I think, but a much bigger discussion, eg because it
requires a new struct).
It's moreso that we're talking about this topic because of the desire to
introduce something like a `requested_device` consumer provided parameter, so
it's not just a new struct, but a way for a consumer to provide information to
a producer in a standardized way at a C-API level as opposed to Python-API
level.
@vyasr's proposal above is interesting, and we could possibly restrict it
even further in that we could document that all evolutions to the protocol that
introduce new parameters should have a default value of `None` that correspond
to the previous behavior. I.E. we could do something like:
# v1 producer
```python
class Foo:
def __arrow_device_array__(self, *, strict=True, **kwargs):
for key, value in kwargs.items():
if value is not None:
raise NotImplementedError(f"{key}" parameter is not
supported)
return capsule
```
# v2 producer
```python
class Foo:
def __arrow_device_array__(self, *, strict=True, requested_device=None,
**kwargs):
for key, value in kwargs.items():
if value is not None:
raise NotImplementedError(f"{key}" parameter is not
supported)
# handle `requested_device` here in a meaningful way where None
implies same behavior as v1
return capsule
```
From a consumer perspective, passing any new parameter becomes purely
optional and they can handle unsupported parameters via `try` / `except`
handling. I don't think signature inspection works here because a producer
implementation may explicitly handle a parameter by explicitly throwing on
non-default values for example.
--
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]
