[Python-Dev] On the METH_FASTCALL calling convention (original) (raw)

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 METHFASTCALL | METHKEYWORDS 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