Le 13/06/2019 à 15:05, Inada Naoki a écrit :
Some functions in cpython are private. These APIs are called from only python executable or DLL. They are not called even from extension modules in stdlib.
Python 3.8 now has a better separation between "private" and "internal" APIs:
* private are "_Py" symbols which are exported in the python DLL: they should not be used, but can be used techically
* internal are symbols defined in internal header files (Include/internal/). Some symbols use PyAPI_FUNC()/PyAPI_DATA(), some only use "extern".
I'm in favor of moving towards "extern" for new internal APIs. I'm trying to keep PyAPI_FUNC/PyAPI_DATA to export symbols in DLL for things which might be useful for 3rd party tools like debuggers or profilers.
Currently, many private APIs uses `PyAPI_FUNC()`.
Well, that's mostly for historical reasons :-)
Is there any downside about having much unnecessary exported functions?
The main risk is that people start to use it, expect these APIs to be there forever, and might be surprised that their code fail with the newer Python.
My plan for http://pythoncapi.readthedocs.io/ is to *reduce* the size of the C API and hide as much as possible implementation details. Export a new function that doesn't make sense outside Python internals goes against this plan.
IMHO private (ex: Include/cpython/ headers) must continue to use PyAPI_FUNC/PyAPI_DATA.
I converted some *private* functions to internal functions, but I didn't always replace PyAPI_FUNC with extern.
For private functions, the contract is that they can change whenever: there is no warranty (and they must not be used ;-)).