Re: [Python-Dev] Comparing PEP 576 and PEP 580
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. 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. Jeroen. [1] https://mail.python.org/pipermail/python-dev/2018-June/153956.html
On Thu, Jul 5, 2018 at 1:13 AM Jeroen Demeyer
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
participants (2)
-
INADA Naoki
-
Jeroen Demeyer