Repository navigation
[C API] Move undocumented private _PyArg C API to pycore_modsupport.h internal C API #110964
Description
Activity
- changed the title
[-][C API] Move undocumented private _PyArg C API to the pycore_modsupport.h internal C API[/-][+][C API] Move undocumented private _PyArg C API to pycore_modsupport.h internal C API[/+]on Oct 17, 2023 Basically, these functions are only used by Argument Clinic.
_PyArg_ParseTupleAndKeywordsFast(), _PyArg_ParseStackAndKeywords(), _PyArg_UnpackKeywords() and _PyArg_UnpackKeywordsWithVararg() have a _PyArg_Parser argument which is not really used without using the internal C API anyway. AC generates complex code using internal header files:
#if defined(Py_BUILD_CORE) && !defined(Py_BUILD_CORE_MODULE) # include "pycore_gc.h" // PyGC_Head # include "pycore_runtime.h" // _Py_ID() #endif (...) #if defined(Py_BUILD_CORE) && !defined(Py_BUILD_CORE_MODULE) #define NUM_KEYWORDS 1 static struct { PyGC_Head _this_is_not_used; PyObject_VAR_HEAD PyObject *ob_item[NUM_KEYWORDS]; } _kwtuple = { .ob_base = PyVarObject_HEAD_INIT(&PyTuple_Type, NUM_KEYWORDS) .ob_item = { &_Py_ID(loop), }, }; #undef NUM_KEYWORDS #define KWTUPLE (&_kwtuple.ob_base.ob_base) #else // !Py_BUILD_CORE # define KWTUPLE NULL #endif // !Py_BUILD_CORE static const char * const _keywords[] = {"loop", NULL}; static _PyArg_Parser _parser = { .keywords = _keywords, .fname = "Future", .kwtuple = KWTUPLE, }; #undef KWTUPLE
PyGC_Head and _Py_ID() API are part of the internal C API, and _Py_ID() must not be used outside Python code base, since we don't guarantee which identifiers are available or not.
_PyArg_ParseStack(args, nargs, format, ...)is likePyArg_ParseTuple(args, format, ...)but forMETH_FASTCALLandMETH_VECTORCALLcalling convention. We should provide an API like_PyArg_ParseStack()in the public API, but I don't know if this API is good or ,not.These helper functions are used by AC. I don't know if it would make sense to make them public or not. They should not be complicated to rewrite if they are no longer usable in the public C API:
- _PyArg_BadArgument()
- _PyArg_CheckPositional()
- _PyArg_NoKeywords()
- _PyArg_NoPositional()
- _PyArg_ParseStack()
- _PyArg_UnpackStack()
- added 4 commits that reference this issue
on Oct 17, 2023 I don't know if this API is good or ,not.
They're vararg functions that return borrowed references, which makes them C-specific and dependent on CPython implementation details. They're quite handy in C, but IMO they'll need a good deal of design work if we're to expose them properly.
IMO they'll need a good deal of design work if we're to expose them properly.
Yeah, I agree with you.
19 remaining items
- added 4 commits that reference this issue
on Nov 28, 2024 - added 2 commits that reference this issue
on Dec 30, 2024 @vstinner yes, I know the issue is closed, but my question is most relevant to this issue.
I'm not asking you to make the functions public, I'm asking you what the intended replacement is. Before fastcall we had PyArg_ParseTupleAndKeywords for argument parsing. The removed functions were the equivalent for fastcall, and fastcall is a public API. So I want to understand whether the intent was to move people away from fastcall or whether there is a different API.
No, the intent was not to move users away from fastcall/vectorcall. The intent was only to remove private functions in the public C API.
I appreciate you taking the time to respond.
I will attempt one more time to rephrase my question as concisely as possible. What is the intended mechanism by which METH_FASTCALL methods should parse their (keyword) arguments?
What is the intended mechanism by which METH_FASTCALL methods should parse their (keyword) arguments?
There is no replacement. If you need a public C API for METH_FASTCALL, please open an issue to request such API.
Reacted by rdb- added a commit that references this issue
on Aug 2, 2026
If a 3rd party C extension uses one of these functions, we should consider adding a clean, documented and tested public function to replace it.
Private functions and structures:
Linked PRs