[Python-Dev] Comparing PEP 576 and PEP 580 (original) (raw)

INADA Naoki songofacandy at gmail.com
Wed Jul 4 23:41:15 EDT 2018

On Thu, Jul 5, 2018 at 1:13 AM Jeroen Demeyer <J.Demeyer at ugent.be> wrote:

On 2018-07-04 03:31, INADA Naoki wrote: > I think both PEPs are relying on FASTCALL calling convention, > and can't be accepted until FASTCALL is stable & public. First of all, the fact that FASTCALL has not been made public should not prevent from discussing those PEPs and even making a (provisional?) decision on them. I don't think that the precise API of FASTCALL really matters that much. More importantly, I don't think that you can separate making FASTCALL public from PEP 576/580. As you noted in [1], making FASTCALL public means more than just documenting METHFASTCALL. In particular, a new API should be added for calling objects using the FASTCALL convention.

I meant _PyArg_ParseStack should be public when METH_FASTCALL is public. Without argument parsing API, it's not practical to implement methods with METH_FASTCALL.

I didn't mean other APIs for calling (e.g. _PyObject_FastCall, etc). Without these APIs, 3rd parties can use METH_FASTCALL for tp_methods and m_methods, like stdlibs. Existing public APIs like PyObject_CallMethod() use FASTCALL internally too.

So we can make public METH_FASTCALL, before make calling APIs public.

And stabilizing calling convention is prerequirements of designing new calling APIs. That's why I suggest discussing METH_FASTCALL first.

Here I mean both an abstract API for arbitrary callables as well as a specific API for certain classes. Since PEP 580 (and possibly also PEP 576) proposes changes to the implementation of FASTCALL, it makes sense to design the public API for FASTCALL after it is clear which of those PEPs (if any) is accepted. If we fix the FASTCALL API now, it might not be optimal when either PEP 576 or PEP 580 is accepted.

I agree that calling APIs should be discusses with PEP 580.

But I didn't mean FASTCALL calling API, but low level FASTCALL calling convention used for tp_methods and m_methods and parsing APIs for it. Does both PEPs suggests changing it? I didn't think so.

-- INADA Naoki <songofacandy at gmail.com>

More information about the Python-Dev mailing list