[Python-Dev] Comparing PEP 576 and PEP 580
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 , making FASTCALL public
> means more than just documenting METH_FASTCALL.
> 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
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
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
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>