On Thu, Jun 21, 2018 at 2:57 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:

On 2018-06-20 17:42, INADA Naoki wrote:
> I don't have any idea about changing METH_FASTCALL more.
> If Victor and Serhiy think so, and PyPy maintainers like it too, I want
> to make it public
> as soon as possible.

There are two different things here:

The first is documenting METH_FASTCALL such that everybody can create
built-in functions using the METH_FASTCALL signature. I think that the
API for METH_FASTCALL (without or with METH_KEYWORDS) is fine, so I
support making it public. This is really just a documentation issue, so
I see no reason why it couldn't be added to 3.7.0 if we're fast.

As Serhiy noted, argument parsing API (_PyArg_ParseStack) is not public too.

So METH_FASTCALL is incomplete for pure C extension authors even if it's documented.

So I don't have strong opinion for documenting it on 3.7.

Consensus about not changing it (without METH_KEYWORDS) on 3.8 seems enough

to me (and Cython).

Then, _PyArg_ParseStack API should be considered first for make it public on Python 3.8.

(bikeshedding: The name *Stack* feels not good. It implies Python VM stack. But this

API can be used not only with VM stack.)

The API for calling functions using the FASTCALL convention is more of a
mess though. There are functions taking keyword arguments as dict and
functions taking them as tuple. As I mentioned in PEP 580, I'd like to
merge these and simply allow either a dict or a tuple. Since this would
require an API change, this won't be for 3.7.0.

I like proposed API too. But I think we should focus on METH_FASTCALL without

METH_KEYWORDS first. Making _PyObject_FastCall() public is significant step for 3.8.

Regards,

INADA Naoki <songofacandy@gmail.com>