jorisvandenbossche commented on issue #38325: URL: https://github.com/apache/arrow/issues/38325#issuecomment-2043536682
> Well, for me the question is: how do we later add options to the API without breaking compatibility with producers that don't implement those options? I am not sure if other options are better than how this works in general for any python API: it's the responsibility of the user to ensure the used keyword is supported. Of course, typically you do that by means of a library version check (for a new keyword you want to use added in a certain version of that library), which is not possible here. But you can still do that as user (i.e. consumer) of the protocol methods, for example by using try/except or by inspecting the signature. It's not very nice, but certainly possible. We could add a "version" number to the capsule protocol, or "capabilities" as Dewey mentioned above (some `__arrow_c_version__` or `__arrow_c_capabilities__`?), but in the end this still keeps the responsibility on the consumer side, but "just" tries to make this check a bit easier (eg a version check to pass different keywords, instead of a try/except with different keywords). But in terms of code on the consumer side, I don't think this will make things that much easier, so I am not sure this is worth the complexity. (also, when we would add something like a "version" concept, we need to be very clear that this is a Python side capsule protocol thing, and not a version of the C Data Interface itself) -- 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]
