[Python-Dev] PEP 580/590 proposals summary
J.Demeyer at UGent.be
Fri May 3 11:38:56 EDT 2019
If we want to have a chance of implementing PEP 580/590 in Python 3.8,
we shouldn't wait too long to make a decision on which proposal to accept.
As a summary, below I'll write the four proposals together with a star
"score" for 3 criteria (there is no obvious best proposal, all have
advantages and disadvantages):
- complexity: more stars is a protocol which is simpler to document and
- implementation: more stars is a simpler implementation of CPython (not
just of the protocol itself, but also the code using the protocol).
- performance: more stars is better performance for *existing* code. I'm
using a minimum of 3 stars here, since the difference is not that big
between the proposals.
Criteria that I am NOT considering:
- The performance for *new* code or the performance of wrappers
generated by Argument Clinic: all proposals score excellent here.
- Complexity of implementations of external classes: this is hard to
judge, since that depends a lot on what those external classes (outside
of CPython) want to do.
- The work to implement the proposal in CPython: this is a one-time only
thing that I'm volunteering to do anyway.
- Extensibility of the protocol: first of all, it's hard to define what
this means exactly. Second, using Petr's idea of putting the flags
inside the instance, every proposal becomes extensible at little cost.
(A) PEP 580
(B) compromise: PEP 580 with a single calling convention
(C) PEP 590 with a single bound method class
(D) PEP 590
I consider Petr's proposal (a more extensible variant of PEP 590 with
flags inside the instance) a minor variation of PEP 590 for this purpose
and no need to score it differently than "plain" PEP 590.
I tried to do this as unbiased as possible, even though I must admit
that this is not really possible.
I'm considering not just the PEP and the existing implementation as
written, but also ideas that haven't been implemented yet such as:
- proposals (A)-(C): rationalization of classes, in particular having a
single class for bound methods (just like in PyPy).
- proposals (B)-(D): Mark Shannon's idea of having a dedicated
vectorcall wrapper for each calling convention (one for METH_O, one for
- using the protocol also for slot wrappers like object.__eq__
I'm NOT considering Petr's proposal of removing support for other
calling conventions like METH_VARARGS because that won't happen any time
More information about the Python-Dev