Hi, In Python 3.9, I *removed* dozens of functions from the *public* C API, or moved them to the "internal" C API: https://docs.python.org/dev/whatsnew/3.9.html#id3
For a few internal C API, I replaced PyAPI_FUNC() with extern to ensure that they cannot be used outside CPython code base: Python 3.9 is now built with -fvisibility=hidden on compilers supporting it (like GCC and clang). I also *added* a bunch of *new* "getter" or "setter" functions to the public C API for my project of hiding implementation details, like making structures opaque: https://docs.python.org/dev/whatsnew/3.9.html#id1 For example, I added PyThreadState_GetInterpreter() which replaces "tstate->interp", to prepare C extensions for an opaque PyThreadState structure. The other 4 new Python 3.9 functions: * PyObject_CallNoArgs(): "most efficient way to call a callable Python object without any argument" * PyModule_AddType(): "adding a type to a module". I hate the PyObject_AddObject() function which steals a reference on success. * PyObject_GC_IsTracked() and PyObject_GC_IsFinalized(): "query if Python objects are being currently tracked or have been already finalized by the garbage collector respectively": functions requested in bpo-40241. Would you mind to elaborate why you consider that these functions must not be added to Python 3.9? > Every one of these functions represents a maintenance burden. > Removing them is painful and takes a lot of effort, but adding them is > done casually, without a PEP or, in many cases, even a review. For the new functions related to hiding implementation details, I have a draft PEP: https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst But it seems like this PEP is trying to solve too many problems in a single document, and that I have to split it into multiple PEPs. > Why are these functions being added? Wasn't 1000 C functions enough? My PEP lists flaws of the existing C API functions. Sadly, fixing flaws requires adding new functions and deprecating old ones in a slow migration. I'm open to ideas how to fix these flaws differently (without having new functions?). As written in my PEP, another approach is to design a new C API on top of the existing one. That's exactly what the HPy project does. But my PEP also explains why I consider that it only fixes a subset of the issues that I listed. ;-) https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst#hpy-project 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/2FSMLZ22XJXGSQQHXDSZHOFOVPETPVWS/ Code of Conduct: http://python.org/psf/codeofconduct/
