Hi,
Update on this issue: I merged my 2 PRs.
https://bugs.python.org/issue46850
The following APIs have been moved to the internal C API:
- _PyFrameEvalFunction type
- _PyInterpreterState_GetEvalFrameFunc()
- _PyInterpreterState_SetEvalFrameFunc()
- _PyEval_EvalFrameDefault()
If you use any of these API in your debugger/profiler project, you
have do add something like the code below to your project:
---
#ifndef Py_BUILD_CORE_MODULE
# define Py_BUILD_CORE_MODULE
#endif
#include <Python.h>
#if PY_VERSION_HEX >= 0x030B00A7
# include <internal/pycore_interp.h> // _PyInterpreterState_SetEvalFrameFunc()
# include <internal/pycore_ceval.h> // _PyEval_EvalFrameDefault()
#endif
---
Contact me if you need help to update your affected projects.
IMO PEP 523 doesn't have to be updated since it already says that the
APIs are private.
Thanks for bringing this up on python-dev, Victor. That was good. But the point of the discussion should've been to continue working with people based on the replies rather than proceeding to merge removals of the APIs after people said they used them. (echoing Steve and Petr here...)
We discussed this on the steering council today. These APIs were in a weird state and despite past decisions at the time of
PEP-523 in 2016 they should be treated as public-ish rather than entirely private. Because we published a document saying "here they are, use them!" and multiple projects have done so to good effect.
For 3.11 we'd like those PRs reverted. We see the following as the better way forward for these APIs:
Add a new #define that can be set before the #include <Python.h> that exposes non-limited but stable within a bugfix/patch releases APIs (ie: Petr's earlier suggestion).
These would be the first to fall within. To do so we should give these, behind that #define, non _-prefixed "public style" names as these are quasi-public and cannot be changed as readily as other true internals. We still, per the PEP, reserve the right to turn these into no-op potentially warning setting APIs in a future release (likely 3.12?) as they are at least documented as being unstable/private in the PEP.
So in 3.11 these should continue to exist as in 3.6-3.10:
- _PyFrameEvalFunction type
- _PyInterpreterState_GetEvalFrameFunc()
- _PyInterpreterState_SetEvalFrameFunc()
- _PyEval_EvalFrameDefault()
- #define protected versions of those without the leading _ become available.
- the _ prefixed versions can go away. People using the APIs should've updated their code to use the new #define and new names when building against >=3.11 by then.
- Whether the APIs continue to be as useful and act as originally claimed in PEP 523 is up to the 3.12 implementors (out of scope for this thread). They occupy a newly defined middle ground between the "forever" style limited API and the "can break even on bugfix/patch release" internal API that wasn't a concept for us in 2016 when PEP 523 was written.