That seems like a good idea in abstract. However, the boundaries will have to be delineated. Many functions beginning _Py are effectively part of the public API even for "well-behaved" 3rd-party extensions because they are used by magic macros. For example, _Py_Dealloc is used by Py_DECREF.
Ideally, we would set the linkage of functions we really didn't want used externally to "hidden". On Sun, Sep 11, 2016, at 01:37, Victor Stinner wrote: > Hi, > > Currently, Python has 3 C API: > > * python core API > * regular API: subset of the core API > * stable API (ABI?), the Py_LIMITED_API thing: subset of the regular API > > For practical purpose, all functions are declared in Include/*.h. > Basically, Python exposes "everything". There are private functions > which are exported using PyAPI_FUNC(), whereas they should only be > used inside Python "core". Technically, I'm not sure that we can get > ride of PyAPI_FUNC() because the stdlib also has extensions which use > a few private functions. > > For Python 3.7, I propose that we move all these private functions in > separated header files, maybe Include/private/ or Include/core/, and > not export them as part of the "regular API". > > The risk is that too many C extensions rely on all these tiny > "private" functions. Maybe for performance. I don't know. > > What do you think? > > See also the issue #26900, "Exclude the private API from the stable API": > http://bugs.python.org/issue26900 > > Victor > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
