PEP 580/590 proposals summary

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
participants (1)
-
Jeroen Demeyer