[Python-Dev] PEP 580/590 discussion (original) (raw)

Petr Viktorin encukou at gmail.com
Thu May 9 18:07:06 EDT 2019

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: - METHFASTCALL (possibly combined with METHKEYWORDS) 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. - METHVECTORCALL (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 METHVECTORCALL (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 METHVECTORCALL equivalent to the existing METHFASTCALL|METHKEYWORDS. But why invent a new name for that? METHFASTCALL|METHKEYWORDS already works. The alias METHVECTORCALL 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.

More information about the Python-Dev mailing list