vyasr commented on issue #38325: URL: https://github.com/apache/arrow/issues/38325#issuecomment-2084373286
I apologize for the exceedingly slow responses here, work has been in a state of transition recently and I'm still getting my bearings a bit. Right, so basically there are three proposals for the API here: 1. All arguments are specified explicitly in the signature, but the default value must be None. 2. In addition to specifying arguments, the interface also accepts `**kwargs`. The producer is responsible for raising a `NotImplementedError` for any unsupported kwargs. 3. In addition to specifying arguments, the interface also accepts `**kwargs`. The producer is free to ignore unsupported keywords or raise as desired. [Your message above](https://github.com/apache/arrow/issues/38325#issuecomment-2046859984) effectively compares 1 and 2. Antoine and Keith's are both of 2. I think 2 is a bit more work for the producer for nearly identical consumer code, but I do think there is a real improvement and it's worth the extra code. A producer-generated `NotImplementedError` can be much more informative than a Python-generated `TypeError` (or an `inspect.signature`-based analysis). I thought 3 might be of interest because of some of the prior discussions around making a [best effort](https://github.com/apache/arrow/issues/38325#issuecomment-2021536856) to honor some keywords but allowing them to also not be honored. In that case it might be easier via `**kwargs` to simply ignore such keywords, but the downside with 3 is that this behavior of accepting but not honoring keywords becomes the default. On further thought, I'm also leaning against that. A producer can always still choose not to honor a particular keyword (without failing outright) with 2, they just have to do so explicitly by handling that keyword rather than letting it be subsumed by `**kwargs`. So I'm on board with not silently ignoring unsupported keywords, I do think that's the better long-term choice. -- 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]
