Home Original page

[Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

Jeroen Demeyer 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
>    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.
More information about the Python-Dev mailing list