[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