[Python-Dev] PEP 580/590 proposals summary

[Jeroen Demeyer]

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 
understand.
- 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.

Proposals:

(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 
METH_VARARGS|METH_KEYWORDS, ...).
- 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 
soon.


Cheers,
Jeroen