[Python-Dev] PEP 580/590 proposals summary

Jeroen Demeyer J.Demeyer at UGent.be
Fri May 3 11:38:56 EDT 2019

Hello all,

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
complexity:     *
implementation: *****
performance:    *****

(B) compromise: PEP 580 with a single calling convention
complexity:     ***
implementation: ****
performance:    ****

(C) PEP 590 with a single bound method class
complexity:     *****
implementation: ***
performance:    ***

(D) PEP 590
complexity:     *****
implementation: *
performance:    ****

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 mailing list