[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Comparing PEP 576 and PEP 580

On Thu, Jul 5, 2018 at 9:02 PM Jeroen Demeyer <J.Demeyer at ugent.be> wrote:
> On 2018-07-05 13:32, INADA Naoki wrote:
> > Core devs interested in this area is limited resource.
> I know and unfortunately there is nothing that I can do about that. It
> would be a pity that PEP 580 (or a variant like PEP 576) is not accepted
> simply because no core developer cares enough.

What you can do is "divide and conquer".  Split PEP in small topics we
can focus.

> > 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.
> Right, that's why I wanted PEP 580 to be only about (c) and nothing
> else. I made the mistake in PEP 575 of also involving (d).
> I still don't understand why we must finish (a) before we can even start
> discussing (c).

Again, "discussing" takes much critical resources.  And we got nothing
in Python 3.8 in worst case.

(c) won't be public unless (a) is public, although main motivation of (c)
is 3rd party tools.  That's why I prefer discussing (a) first.  Without (a),
discussion about (c) will not born anything in Python 3.8.

This is only advice from me and you can start discussion about (c),
like you ignored my advice about creating realistic benchmark for
calling 3rd party callable before talking about performance...

> > Reference implementation helps discussion.
> METH_FASTCALL and argument parsing for METH_FASTCALL is already
> implemented in CPython. Not in documented public functions, but the
> implementation exists.
> And PEP 580 also has a reference implementation:
> https://github.com/jdemeyer/cpython/tree/pep580

Yes I know.  I described just "I didn't say wait for implement".

INADA Naoki  <songofacandy at gmail.com>