On Wed, Mar 30, 2022 at 9:26 PM Sebastian Berg <sebast...@sipsolutions.net> wrote: > That is fair, although there are documented underscored ones: > https://docs.python.org/3/search.html?q=_Py > > I suppose that means all bets are off _unless_ it is documented or > later adopted as stable API (e.g. `_PyObject_Vectorcall`). > > With that, the only "not obviously OK" use in NumPy that I am aware of > is `_Py_HashDouble` (it seems undocumented). > > Maybe "unless documented" is just a clear enough distinction in > practice. > Although, to some degree, I think it would be clearer if symbols that > have a realistic chance of changing in bug-fix releases had an > additional safe-guard.
Since Python 3.7, there is a work-in-progress to (1) better hide internal C API functions and to (2) promote *private* C API functions being used by 3rd party projects as documented and well tested *public* functions. An example of (2) is the addition of float pack/unpack public functions, like PyFloat_Pack8() and PyFloat_Unpack8(): https://docs.python.org/dev/c-api/float.html#pack-and-unpack-functions There were previously known as private _PyFloat_Pack8() and _PyFloat_Unpack8() functions. They are used by a few serialization projects like msgpack. When they were made public, tests were added and the existing comments were converted to documentation and enhanced. I discovered that these private functions were used when I moved them to the internal C API in bpo-46906 (1) and it broke a few projects. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/DT2PUGWPOSZOJZLR4VOMPS6QOS3PDRYR/ Code of Conduct: http://python.org/psf/codeofconduct/
