[Python-Dev] PEP 580/590 discussion

[Petr Viktorin]

On 5/9/19 5:33 PM, Jeroen Demeyer wrote:
> 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.

Then we can, in the spirit of minimalism, not add METH_VECTORCALL at all.


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

METH_FASTCALL is currently not documented, and it should be renamed 
before it's documented. Names with "fast" or "new" generally don't age well.