[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: Mark: > PEP 523 is quite vague, but the rationale indicates that exposing > `eval_frame` is for "a method-level JIT". PEP 523 did not suggest adding an > API. I disagree, the PEP is quite explicit: "Third-party code may then set their own frame evaluation

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: Mark Shannon: `PyThreadState` is an internal opaque data structure, which means we are free to change it. I guess that you mean PyInterpreterState which was moved to the internal C API in Python 3.8. It was part of public C API in Python 3.7. See commit

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: Somehow related, I just created bpo-39946: "Is it time to remove _PyThreadState_GetFrame() hook?". -- ___ Python tracker ___

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: For me, the *short term* goal is to find a way to limit the number of broken C extension module while we modify the C API to make it more opaque. We cannot reach all goals at once (opaque C API, subinterpreter, more optimizations, etc). We have to move step

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: > Why not do so by reverting the change that caused it? Making PyInterpreterState structure private was motivated by the subinterpreters work but also by the work on cleaning the C API. Over time, PyInterpreterState became more and more complex because many

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

Mark Shannon added the comment: I'm not suggesting immediate removal of PEP 532. I am requesting that you don't add a new function to the C API that will prevent implementation of many meaningful optimizations to CPython. PEP 532 does not add any API functions. I understand that you want to

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: > I think you mean PEP 352? And a more formal proposal to withdraw would need > to be made and that has not happened, so assume the PEP is still accepted and > final. I mean PEP 523 "Adding a frame evaluation API to CPython" as I wrote in the title, sorry

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

Brett Cannon added the comment: > Mark Shannon listed flaws in the PEP 532 and suggest to withdraw this PEP. I think you mean PEP 352? And a more formal proposal to withdraw would need to be made and that has not happened, so assume the PEP is still accepted and final. --

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

Change by STINNER Victor : -- title: Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals -> PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression) versions: -Python 3.8