On Wed, Mar 23, 2022 at 2:48 AM Petr Viktorin <encukou@gmail.com> wrote:
On 22. 03. 22 19:07, Victor Stinner wrote:
Hi,
I proposed two PRs to move the private C API (Include/cpython/) of PEP 523 "Adding a frame evaluation API to CPython" to the internal C API (Include/internals/):
* https://github.com/python/cpython/pull/32052 * https://github.com/python/cpython/pull/32054
API:
* _PyFrameEvalFunction type * _PyInterpreterState_GetEvalFrameFunc() * _PyInterpreterState_SetEvalFrameFunc() * (undocumented) _PyEval_EvalFrameDefault()
The private API to get/set the eval function *is* documented at:
https://docs.python.org/dev/c-api/init.html#c._PyInterpreterState_GetEvalFra...
I added the Get/Set functions so debuggers don't have to access directly to the PyInterpreterState structure which has been moved to the internal C API in Python 3.8.
This API causes me multiple issues:
* It's a private API and I'm trying to remove the private API from the public C API header files. * The _PyFrameEvalFunction type is not stable: it got a new "tstate" parameter in Python 3.9 and the type of the second parameter changed from PyFrameObject* to _PyInterpreterFrame* in Python 3.11. * These functions use the _PyInterpreterFrame type which is part of the internal C API.
While Pyston didn't bring a JIT compiler to Python with PEP 523, debuggers were made faster by using this API. Debuggers like pydevd, debugpy and ptvsd use it.
I propose to move theses API to the internal header files (Include/internals/) to clarify that it's not part of the public C API and that there is no backward compatibility warranty.
The change is being discussed at: https://bugs.python.org/issue46850
--
PEP 523 API added more private functions for code objects:
* _PyEval_RequestCodeExtraIndex() * _PyCode_GetExtra() * _PyCode_SetExtra()
The _PyEval_RequestCodeExtraIndex() function seems to be used by the pydevd debugger. The two others seem to be unused in the wild. I'm not sure if these ones should be moved to the internal C API. They can be left unchanged, since they don't use a type only defined by the internal C API.
PEP 523 clearly meant for these to be used by external tools, but made them private. That sounds like a contradiction.
Brett/Dino, what was the intent here?
From the PEP <https://peps.python.org/pep-0523/#expanding-pycodeobject>: "The API is purposefully listed as private to communicate the fact that there are no semantic guarantees of the API between Python releases." -Brett
IMO, if external code should use these, they should lose the leading underscore.