Home Original page

[Python-Dev] PEP 575 (Unifying function/method classes) update

Jeroen Demeyer J.Demeyer at UGent.be
Tue Jun 19 07:58:51 EDT 2018 
On 2018-06-18 15:09, Victor Stinner wrote:
> There are multiple issues with tp_fastcall:

Personally, I think that you are exaggerating these issues.

Below, I'm writing the word FASTCALL to refer to tp_fastcall in your 
patch as well as my C call protocol in the PEP-in-progress.

> * ABI issue: it's possible to load a C extension using the old ABI,
> without tp_fastcall: it's not possible to write type->tp_fastcall on
> such type. This limitation causes different issues.

It's not hard to check for FASTCALL support and have a case distinction 
between using tp_call and FASTCALL.

> * If tp_call is modified, tp_fastcall may be outdated.

I plan to support FASTCALL only for extension types. Those cannot be 
changed from Python.

If it turns out that FASTCALL might give significant benefits also for 
heap types, we can deal with those modifications: we already need to 
deal with such modifications anyway for existing slots like __call__.

> * Many public functions of the C API still requires the tuple and dict
> to pass positional and keyword arguments, so a compatibility layer is
> required to types who only want to implement FASTCALL. Related issue:
> what is something calls tp_call with (args: tuple, kwargs: dict)?
> Crash or call a compatibility layer converting arguments to FASTCALL
> calling convention?

You make it sound as if such a "compatibility layer" is a big issue. You 
just need one C API function to put in the tp_call slot which calls the 
object instead using FASTCALL.
More information about the Python-Dev mailing list