[Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579 (original) (raw)

INADA Naoki songofacandy at gmail.com
Thu Jun 21 04:25:40 EDT 2018


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

On 2018-06-20 17:42, INADA Naoki wrote: > I don't have any idea about changing METHFASTCALL 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 METHFASTCALL such that everybody can create built-in functions using the METHFASTCALL signature. I think that the API for METHFASTCALL (without or with METHKEYWORDS) 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 at gmail.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180621/4c7102e9/attachment.html>



More information about the Python-Dev mailing list