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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
