[Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods (original) (raw)

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:

- PyCCallFastCall() 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 ccfunc or is it first transformed?

Transformed (obviously, otherwise it would be a huge backwards incompatibility problem).

- there's CCALLOBJCLASS and CCALLSLICESELF 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