[Python-Dev] On the METH_FASTCALL calling convention
Jeroen Demeyer
J.Demeyer at UGent.be
Fri Jul 6 06:23:20 EDT 2018
On 2018-07-06 06:07, INADA Naoki wrote:
> Maybe, one way to improve METH_FASTCALL | METH_KEYWORDS can be this.
> kwds can be either tuple or dict.
But that would be just pushing the complexity down to the callee. I'd
rather have a simpler protocol at the expense of a slightly more complex
supporting API.
I also don't see the point: the calls where performance truly matters
typically don't use keyword arguments anyway (independently of whether
the called function accepts them).
Moreover, the large majority of functions take normal keyword arguments,
not **kwargs. When parsing those arguments, the dict would need to be
unpacked anyway. So you don't gain much by forcing the callee to handle
that instead of doing it in PyCCall_FASTCALL().
Functions just passing through **kwargs (say, functools.lru_cache) don't
need a dict either: they can implement the C call protocol of PEP 580
with METH_FASTCALL and then call the wrapped function also using FASTCALL.
So really the only remaining case is when the callee wants to do
something with **kwargs as dict. But I find it hard to come up with a
natural use case for that, especially one where performance matters. And
even then, that function could just use METH_VARARGS.
So I don't see any compelling reason to allow a dict in METH_FASTCALL.
Jeroen.
More information about the Python-Dev
mailing list