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_GetEvalFrameFunc
>
> 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: "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.