[Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
J.Demeyer at UGent.be
Wed Jun 20 10:32:09 EDT 2018
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
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 (obviously, otherwise it would be a huge backwards
> - 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
More information about the Python-Dev