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.