RetroSearch Browse

Tue Jul 10 19:20:12 EDT 2018 · https://mail.python.org/pipermail/python-dev/2018-July/154581.html

2018-07-07 10:55 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
> There is my idea. Split every of keyword argument parsing functions on two
> parts. The first part linearize keyword arguments, it converts positional
> and keyword arguments (in whatever form they were presented) into a linear
> array of PyObject* (with NULLs for not specified optional arguments). The
> second part is common and similar to _PyArg_ParseStack(), but supports
> NULLs. It converts an array of PyObject* to a sequence of C values. I tried
> to implement this idea, is is not simple, and results were mixed, but I
> don't loss a hope.
>
> And here we return to METH_FASTCALL|METH_KEYWORDS. The first part of
> handling arguments can be made outside of the C function, by the calling
> API. Then the signature of the C function can be simpler, the same as for
> METH_FASTCALL. But we need to expose the list of keyword parameter names as
> an attribute of CFunction.
>
> I don't know whether this ides is vital or dead, but I' going to try it. And
> implementing it will change the METH_FASTCALL|METH_KEYWORDS calling
> convention a lot.

I don't understand why changing the implementation of PyArg_Parse*()
would require to require the FASTCALL calling convention?

Victor

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-July/154581.html below:

[Python-Dev] On the METH_FASTCALL calling convention