Hi,
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 ;-)).
Victor
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/KNICIXJ2ZYYGGDTSC4IFP76GCRIYHLRS/
