[Python-Dev] PEP 580/590 discussion

[Jeroen Demeyer]

On 2019-05-09 20:30, Petr Viktorin wrote:
> The underlying C function should not need to know how to extract
> "self" from the function object, or how to handle the argument
> offsetting.
> Those should be implementation details.

Maybe you misunderstood my proposal. I want to allow both for extra 
flexibility:

- METH_FASTCALL (possibly combined with METH_KEYWORDS) continues to work 
as before. If you don't want to care about the implementation details of 
vectorcall, this is the right thing to use.

- METH_VECTORCALL (using exactly the vectorcallfunc signature) is a new 
calling convention for applications that want the lowest possible 
overhead at the cost of being slightly harder to use.

Personally, I consider the discussion about who is supposed to check 
that a function returns NULL if and if an error occurred a tiny detail 
which shouldn't dictate the design. There are two solutions for this: 
either we move that check one level up and do it for all vectorcall 
functions. Or, we keep the existing checks in place but we don't do that 
check for METH_VECTORCALL (this is already more specialized anyway, so 
dropping that check doesn't hurt much). We could also decide to enable 
this check only for debug builds, especially if debug builds are going 
to be easier to use thank to Victor Stinner's work.

> I see the value in having METH_VECTORCALL equivalent to the existing
> METH_FASTCALL|METH_KEYWORDS.

But why invent a new name for that? METH_FASTCALL|METH_KEYWORDS already 
works. The alias METH_VECTORCALL could only make things more confusing 
(having two ways to specify exactly the same thing). Or am I missing 
something?


Jeroen.