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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
