I think both PEPs are relying on FASTCALL calling convention,
and can't be accepted until FASTCALL is stable & public.

There are enough time before Python 3.8 is released.
Let's go step by step.


On Wed, Jul 4, 2018 at 12:10 AM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
Hello all,

in order to make reviewing PEP 576/580 easier and possibly take some
ideas from one PEP to the other, let me state the one fundamental
difference between these PEPs. There are many details in both PEPs that
can still change, so I'm focusing on what I think is the big structural

To be clear: I'm referring to the PEP 576 version at
(this really should be merged in the main PEP repo).

Both PEPs add a hook for fast calling of C functions. However, they do
that on a different level. Let's trace what _PyObject_FastCallKeywords()
currently does when acting on an instance of builtin_function_or_method:

A. _PyObject_FastCallKeywords()
B. _PyCFunction_FastCallKeywords()
      which calls
C. _PyMethodDef_RawFastCallKeywords()
      which calls
D. the actual C function (*ml_meth)()

PEP 576 hooks the call A->B while PEP 580 hooks the call B->D (getting
rid of C).

Advantages of the high-level hook (PEP 576):
* Much simpler protocol than PEP 580.
* More general since B can be anything.
* Not being forced to deal with "self".
* Slightly faster when you don't care about B.

Advantages of the low-level hook (PEP 580):
* No need to duplicate the code from B (see the various existing
_{FOO}_FastCallKeywords functions).
* Enables certain optimizations because other code can make assumptions
about what B does.

In my personal opinion, the last advantage of PEP 580 is really
important: some existing optimizations depend on it and it also allows
extending the protocol in a "performance-compatible" way: it's easy to
extend the protocol in a way that callers can benefit from it.

Anyway, it would be good to have some guidance on how to proceed here. I
would really like something like PEP 580 to be accepted and I'm willing
to put time and effort into achieving that.

Python-Dev mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com

INADA Naoki  <songofacandy@gmail.com>