[Python-Dev] PEP 580/590 discussion

[Jeroen Demeyer]

Hello,

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 
CCALL_DEFARG|CCALL_FASTCALL|CCALL_KEYWORDS.

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.

Background:

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?
Jeroen.