Argument Clinic could be modified to have an option to only use C API of the limited C API. Cython is working on a similar option (restraint emitted code to the limited C API).
I hesitated to make the macro public since… it’s a macro and I am trying to move the Python C API avoid from macro, I mean, I wrote PEP 670 with Erlend PEP 670 – Convert macros to functions in the Python C API | peps.python.org But well, maybe such macro is better than the previous cast which emitted a C++ compiler warning (“old-style cast”).
No, we should not. AC is internal and CPython-only, so it can use CPython-specific API.
If AC is needed outside CPython, IMO it should be forked (and probably improved), like pegen.
It can be modified to have two build modes: one using the internal API, one using public or limited API (or we can have a 3rd mode for the limited API). CPython itself would benefit, I would like to be able to build a stdlib extension module with the limited API and use AC (since AC is great for docstring and inspect.signature()). See: https://github.com/python/cpython/issues/85283
Maintaining a fork outside Python sounds counter productive to me.
So, seems like this sort of went in the other direction, huh?
With the Argument Clinic implementation in current CPython’s Tools/clinic/, even if I call clinic.py --limited it will emit includes of internal headers, which unless I’m missing something makes its code unusable outside of the CPython tree?
The limited C API is not fully supported. Some kind of arguments still use the internal C API. It’s a work in progress. Which arguments use the internal C API for you?
This option is experimental. It helps us to see what happens when try to use the limited C API globally, what should be done to make it usable. If some private C API is often used, we should consider adding the corresponding public C API. If some private C API is rarely used, we can consider making Argument Clinic not using it with the limited C API.
If you want to use Argument Clinic in your project, consider writing custom converters.
Well, integers, for one! That pycore_long.h header being included is located at /usr/include/python3.12/internal/pycore_long.h on my system, so I was taking it to be an internal header.