[Python-Dev] PEP 580/590 discussion
J.Demeyer at UGent.be
Fri Apr 26 06:54:35 EDT 2019
after reading the various comments and thinking about it more, let me
propose a real compromise between PEP 580 and PEP 590.
My proposal is: take the general framework of PEP 580 but support only a
single calling convention like PEP 590. The single calling convention
supported would be what is currently specified by the flag combination
This way, the flags CCALL_VARARGS, CCALL_FASTCALL, CCALL_O,
CCALL_NOARGS, CCALL_KEYWORDS, CCALL_DEFARG can be dropped.
This calling convention is very similar to the calling convention of PEP
590, except that:
- the callable is replaced by a pointer to a PyCCallDef (the structure
from PEP 580, but possibly without cc_parent)
- there is a self argument like PEP 580. This implies support for the
CCALL_SELFARG flag from PEP 580 and no support for the
PY_VECTORCALL_ARGUMENTS_OFFSET trick of PEP 590.
I added support for all those calling conventions in PEP 580 because I
didn't want to make any compromise regarding performance. When writing
PEP 580, I assumed that any kind of performance regression would be a
reason to reject PEP 580.
However, it seems now that you're willing to accept PEP 590 instead
which does introduce performance regressions in certain code paths. So
that suggests that we could keep the good parts of PEP 580 but reduce
its complexity by having a single calling convention like PEP 590.
If you compare this compromise to PEP 590, the main difference is
dealing with bound methods. Personally, I really like the idea of having
a *single* bound method class which would be used by all kinds of
function classes without any loss of performance (not only in CPython
itself, but also by Cython and other C extensions). To support that, we
need something like the PyCCallRoot structure from PEP 580, together
with the special handling for self.
About cc_parent and CCALL_OBJCLASS: I prefer to keep that because it
allows to merge classes for bare functions (not inside a class) and
unbound methods (functions inside a class). Concretely, that could
reduce code duplication between builtin_function_or_method and
method_descriptor. But I'm also fine with removing cc_parent and
CCALL_OBJCLASS. In any case, we can decide that later.
What do you think?
More information about the Python-Dev