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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
