[Python-Dev] Comparing PEP 576 and PEP 580

INADA Naoki songofacandy at gmail.com
Thu Jul 5 07:32:20 EDT 2018


On Thu, Jul 5, 2018 at 6:31 PM Jeroen Demeyer <J.Demeyer at ugent.be> wrote:
>
> On 2018-07-05 05:41, INADA Naoki wrote:
> > And stabilizing calling convention is prerequirements of designing new
> > calling APIs.
>
> I don't see why. I made my PEP with the assumption that the
> METH_FASTCALL calling convention won't change. As far as I know, nobody
> advocated for changing it. But even if we decide to change
> METH_FASTCALL, I could trivially adapt my PEP.

Serhiy said "the protocol for keyword parameters is more complex and
still can be changed."
https://mail.python.org/pipermail/python-dev/2018-June/153949.html

>
> > That's why I suggest discussing METH_FASTCALL first.
>
> I certainly agree that it's a good idea to discuss METH_FASTCALL, but I
> still don't see why that should block the discussion of PEP 576/580.

Core devs interested in this area is limited resource.
As far as I understand, there are some important topics to discuss.

a. Low level calling convention, including argument parsing API.
b. New API for calling objects without argument tuple and dict.
c. How more types can support FASTCALL, LOAD_METHOD and CALL_METHOD.
d. How to reorganize existing builtin types, without breaking stable ABI.

It's difficult to understand all topics in both PEPs at once.
I suggested to focus on prerequirements first because it helps us to join
discussion without understand whole two PEPs.

>
> I can understand that you want to wait to *implement* PEP 576/580 as
> long as METH_FASTCALL isn't public. But we should not wait to *discuss*
> those PEPs.
>

I didn't want wait to "implement".  Discussion is the most critical path.
Reference implementation helps discussion.

Regards,

>
> Jeroen.
>

--
INADA Naoki  <songofacandy at gmail.com>


More information about the Python-Dev mailing list