>
> 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.
>
Just to note, the pydevd/debugpy debuggers actually uses all of those APIs.

i.e.:

https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L187
https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L232
https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L311

The debugger already has workarounds because of changes to evaluation api
over time (see:
https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L491)
and I know 3.11 won't be different.

I'm ok with changes as I understand that this is a special API -- as long
as there's still a way to use it and get the information needed (the
debugger already goes through many hops because it needs to use many
internals of CPython -- in every new release it's a **really** big task to
update to the latest version as almost everything that the debugger relies
to make debugging fast changes across versions and I never really know if
it'll be possible to support it until I really try to do the port -- I
appreciate having less things in a public API so it's easier to have
extensions work in other interpreters/not recompiling on newer versions,
but please keep it possible to use private APIs which provides the same
access that CPython has to access things internally for special cases such
as the debugger).

Maybe later on that PEP from mark which allows a better debugger API could
alleviate that (but until then, if possible I appreciate it if there's some
effort not to break things unless really needed -- ideally with
instructions on how to port).

Anyways, to wrap up, the debugger already needs to be built with
`Py_BUILD_CORE_MODULE=1` anyways, so, I guess having it in a private API
(as long as it's still accessible in that case) is probably not a big issue
for the debugger and having setters/getters to set it instead of relying on
`state.interp.eval_frame` seems good to me.

Cheers,

Fabio
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XPDT55ANVKHGG74D62HDBOFLC4EXWJ26/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to