Thank you!
And thank you again for the PEP. It is a great feature, and I have no doubt in your ability to make a self-consistent feature.
I can also see how these “edges” where the feature meets the rest of the system can be annoying – they’re not part of the actual improvement, and they can be under-documented and used in surprising ways. But that’s also why I think a PEP should specify them as carefully than the feature itself, if not more.
So please bear with me. (Or maybe delegate this so you focus on the meat of the change?)
With the current wording, “using PEP 523” as it is written – that is, setting PyInterpreterState.eval_frame directly – will avoid the exception.
I suggest adding the following:
To avoid bypassing
_PyInterpreterState_SetEvalFrameFunc()by
settingPyInterpreterState.eval_framedirectly (as specified in
:pep:523), the field will be renamed to_eval_frameand documentation
will be updated to avoid references to :pep:523.
I’m happy to help with that documentation update, but since I’m not an expert in this area and don’t know who’ll be affected, I’d go through the PEP process on the decision.
Another place where I’m not sure how this PEP interacts with the rest of CPython is Quickening. I’m still unhappy about PEP 659 being referred to while it’s still a draft.
Was PEP 659 implemented as written, or are there any notable changes?
For better introspection in Tool identifiers, may I suggest an API like:
sys.monitoring.use_tool_id(id, name=None) -> None
sys.monitoring.free_tool_id(id) -> None
sys.monitoring.get_used_tools() -> dict[int, str|None] # unclaimed IDs are not included
# str(name) should help a human identify the tool, name has no requirements beyond that
so use_tool_id can raise ValueError: monitoring ID 3 is already used by Cinder, and tools can get the name for their own error messages, like warnings on the profiler+debugger case mentioned in Events in callback functions.
I sent PR 2767 with some smaller suggestions.