On Thu, Jul 5, 2018 at 1:13 AM Jeroen Demeyer <j.deme...@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 <songofaca...@gmail.com> _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
