This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: PyArg_Parse* for vectorcall?
Type: enhancement Stage:
Components: C API Versions: Python 3.11
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jkloth, methane, ronaldoussoren, serhiy.storchaka
Priority: normal Keywords:

Created on 2021-05-23 10:14 by ronaldoussoren, last changed 2022-04-11 14:59 by admin.

Messages (4)
msg394194 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2021-05-23 10:14
I'm currently converting some extensions of my own to vectorcall and an annoying change between the old call protocol and vectorcall is that the latter has no public equivalent to the PyArg_Parse family of functions.

There is "_PyArg_ParseStack*" in the CPython implementation, but those functions are not part of the public API.

Please consider making "_PyArg_ParseStack" public.
msg394195 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-05-23 11:17
There are no problems with exposing _PyArg_ParseStack(). Although I am arguing that it would be better to rename it to _PyArg_ParseArray.

But _PyArg_ParseStackAndKeywords() is more complicated. It uses a private structure _PyArg_Parser allocated on the stack. It was not important while it was private, but the layout of _PyArg_Parser cannot be changed after making it a public structure unless we add support for expanding supporting of future versions of the structure from initial. This requires attentive development of future design. Fortunately most of the functions and methods in CPython have already been converted to Argument Clinic, so it's easier now to experiment with designs by making Argument Clinic generating different code. Although this is still an amount of work.
msg394363 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2021-05-25 14:39
Annoyingly the keywords variant is the most interesting to expose :-) due to the complexity of correctly interpreting keyword arguments.

I agree that we should be careful in exposing the APIs using _PyArg_Parser, although it should be easer to expose it only in the non-stable ABI because extensions should be recompiled for new python releases anyway.

That said, I won't work on this issue myself (or at least not anytime soon). My current use case doesn't use keyword arguments, and open coding the calls to PyArg_ParseTuple is easy enough for now (even if that leads to more boilerplate).
msg394372 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-05-25 15:39
There are alternative ideas of parsing API which should be considered:

1. Linearize keyword arguments using _PyArg_UnpackKeywords() and parse the linear array of arguments with a variant of _PyArg_ParseStack().

2. Parse arguments outside of the user function and pass already parsed values (as in Argument Clinic). Or just pre-process keyword arguments and pass a continuous array of arguments with possible NULLs for optional parameters. Specification for parsing arguments should be added to PyMethodDef.

I do not know what idea will work better, it needs experimentation.
Date User Action Args
2022-04-11 14:59:46adminsetgithub: 88380
2021-05-25 15:39:24serhiy.storchakasetmessages: + msg394372
2021-05-25 14:39:57ronaldoussorensetmessages: + msg394363
2021-05-24 07:06:18methanesetnosy: + methane
2021-05-23 13:10:05jklothsetnosy: + jkloth
2021-05-23 11:17:30serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg394195
2021-05-23 11:10:32ronaldoussorensettype: enhancement
2021-05-23 10:14:52ronaldoussorencreate