On 2018-06-20 16:09, Antoine Pitrou wrote: > But there seems to be some complication on top of that: > > - PyCCall_FastCall() accepts several types for the keywords, even a > dict; That is actually a *simplification* instead of a *complication*. Currently, there is a huge amount of code duplication between _PyMethodDef_RawFastCallKeywords and _PyMethodDef_RawFastCallDict. Folding both of these in one function actually makes things simpler. > does it get forwarded as-is to the `cc_func` or is it first > transformed? Transformed (obviously, otherwise it would be a huge backwards incompatibility problem). > - there's CCALL_OBJCLASS and CCALL_SLICE_SELF which have, well, > non-obvious behaviour (especially the latter), especially as it is > conditioned on the value of other fields or flags It's actually quite obvious when you think of it: both are needed to support existing use cases. Perhaps it's just not explained well enough in the PEP. > I wonder if there's a way to push some of the specificities out of the > protocol and into the C API that mediates between the protocol and > actual callers? Sorry, I have no idea what you mean here. Actually, those flags are handled by the C API. The actual C functions don't need to care about those flags.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4