[Python-Dev] PEP 580/590 discussion
Jeroen Demeyer
J.Demeyer at UGent.be
Thu May 9 17:33:47 EDT 2019
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.
More information about the Python-Dev
mailing list