jorisvandenbossche commented on issue #38325: URL: https://github.com/apache/arrow/issues/38325#issuecomment-2066149544
> How would we distinguish from whether an API was provided with a default value explicitly vs because that value is the default in the signature itself? The idea mentioned earlier was to require that any new keyword will have a default of `None`: Keith proposed this first (https://github.com/apache/arrow/issues/38325#issuecomment-2046321496): > 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. And later also Antoine (https://github.com/apache/arrow/issues/38325#issuecomment-2046967106): > Also, we can mandate that `None` be the default value for all optional arguments we add in the future. This makes checking the `kwargs` for non-default values very easy (with each time an example code of how handling that would look like, see the links) To me, the main reason that I don't really like the idea of silently ignoring unsupported keywords is that then as a consumer you still need to check in the resulting data if your keyword was honored, and have a fall back for when it was not honored. At that point it becomes very similar to a try/except. For the example of a `requested_device` keyword, if this keyword would be ignored if not supported by some producer, essentially that becomes like a "best-effort" keyword (a behaviour which we didn't want for the keyword itself), and the consumer will still have to check the device type of the returned struct because it cannot be sure that it will have the device type that they requested. --- > Perhaps we should start sketching out some slightly more realistic examples than the ones in this thread so far, both of the v0 proposal and potential changes we could envision in v1 (even if we don't plan to implement them right now) Fully agreed that concrete examples are helpful. But I think we can essentially treat the`requested_device` as an example? (for the example assuming we would not yet add that keyword right now but only in a year from now or so). So then a v0 would have no keywords, and a v1 would add the `requested_device` keyword. I think that is a realistic example? In https://github.com/apache/arrow/issues/38325#issuecomment-2046859984 above, I already showed some different code snippets how it would like for a consumer to use this keyword depending on which mechanism we use to add new keywords (no special handling, let the producer raise for non-default value, allow asking to silence errors and ignore unsupported keywords). -- 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]
