On Thu, Jun 21, 2018 at 2:57 PM Jeroen Demeyer <j.deme...@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 <songofaca...@gmail.com>
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
