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.

Author vstinner
Recipients vstinner
Date 2020-06-25.08:54:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Python stdlib has around 139 extension modules. Not all of them *need* to use internal C API. I'm interested to try to convert a bunch of them to the limited C API, as part of my work on the PEP 620. IMHO "Eating your own dog food" is a good practice to ensure that the limited C API is usable.

Currently, the stdlib has exactly one extension module using the limited C API: the xxlimited module built with Py_LIMITED_API macro defined as 0x03050000 in By the way, maybe Py_LIMITED_API should be defined in xxlimited.c, rather than in

xxlimited.c is not built if Python is built in debug mode. I'm not sure why.

The main limitation to use the limited C API for stdlib is Argument Clinic which attempts to always emit the most efficient code, like using the METH_FASTCALL calling convention and use private functions like _PyArg_CheckPositional() or "static _PyArg_Parser _parser".

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 already tried to convert stdlib extensions to the limited C API in bpo-39573. I found other issues:

* PyTypeObject is opaque and so it's not possible to implement a deallocator function (tp_dealloc) which calls tp_free like: Py_TYPE(self)->tp_free((PyObject*)self);
* _Py_IDENTIFIER() is not part of the limited C API
Date User Action Args
2020-06-25 08:54:20vstinnersetrecipients: + vstinner
2020-06-25 08:54:20vstinnersetmessageid: <>
2020-06-25 08:54:20vstinnerlinkissue41111 messages
2020-06-25 08:54:18vstinnercreate