[Python-Dev] Comparing PEP 576 and PEP 580

[INADA Naoki]

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 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
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>