PyArg_Parse* for vectorcall?

[ronaldoussoren]

BPO	44214
Nosy	@ronaldoussoren, @jkloth, @methane, @serhiy-storchaka

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['expert-C-API', 'type-feature', '3.11'] title = 'PyArg_Parse* for vectorcall?' updated_at = user = 'https://github.com/ronaldoussoren' ``` bugs.python.org fields: ```python activity = actor = 'serhiy.storchaka' assignee = 'none' closed = False closed_date = None closer = None components = ['C API'] creation = creator = 'ronaldoussoren' dependencies = [] files = [] hgrepos = [] issue_num = 44214 keywords = [] message_count = 4.0 messages = ['394194', '394195', '394363', '394372'] nosy_count = 4.0 nosy_names = ['ronaldoussoren', 'jkloth', 'methane', 'serhiy.storchaka'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue44214' versions = ['Python 3.11'] ```

[ronaldoussoren]

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.

[serhiy-storchaka]

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.

[ronaldoussoren]

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).

[serhiy-storchaka]

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.