[Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
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 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
So METH_FASTCALL is incomplete for pure C extension authors even if it's
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
METH_KEYWORDS first. Making _PyObject_FastCall() public is significant
step for 3.8.
INADA Naoki <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev