On 24. 03. 22 20:06, Fabio Zadrozny wrote:
Em qui., 24 de mar. de 2022 às 15:39, Fabio Zadrozny <fabi...@gmail.com
<mailto:fabi...@gmail.com>> escreveu:
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#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#L232>
https://github.com/fabioz/PyDev.Debugger/blob/main/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L311
<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
<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
I think the main issue here is the compatibility across the same version
though... is it possible to have some kind of guarantee on private APIs
that something won't change across micro-releases?
Currently we don't really have that (except that in practice, bugfix
releases tend to not need internal API changes.)
I.e.: having the frame evaluation function change across major releases
and having them be reworked seems reasonable, but then having the frame
evaluation be changed across micro-releases wouldn't be.
So, I'm ok in pushing things to the internal API, but then I still would
like guarantees about the compatibility of that API in the same major
release (otherwise those setters/getters/frame evaluation should
probably remain on the public API if the related structure was moved to
the internal API).
Perhaps we need a new "tier" of C API for debuggers -- API that's
guaranteed stable for a major release, and if it's changed it should
always break with compile errors (e.g. the function gets a new
argument), rather than silently change semantics.
The internal API Cython & greenlet need might go it this category too.
_______________________________________________
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/OF4UNE22IDDJDJVQZMOUXHELAYEFCJ45/
Code of Conduct: http://python.org/psf/codeofconduct/
