Hi Pablo,
On 20/01/2021 3:18 pm, Pablo Galindo Salgado wrote:
>It depends on what you mean by "similar tools".
Any 3rd party tool or debugger that is printing merged stacks. (There
are many: gdb helpers, lldb helpers, TotalView debugger, py-spy, ...)
For in-process tools, then the API will continue to work.
For out-of-process debuggers, then the author's are on their own.
But that's always been the case.
The source code is public, and it won't be any more opaque than it is at
the moment :)
I agree with that, but we need to have in mind that this will break
these tools and therefore we need to be aware on how difficult will
be to overcome the new situation. Is not the same that a small or
medium change is required than the case where is virtually impossible
to overcome. If we were designing the interpreter from scratch that would
not matter, but with an existing ecosystem of tools, it does. Breaking tools
in an established ecosystem has always been a major complaint of users
when we do major releases.
Do you have any specific examples?
I feel the responsibility for this belongs with the tool authors.
If they aren't using the C-API, or requesting an alternative interface
should the API be insufficient, then they can't really complain.
Notice as well that the gdb helpers *are* an out-of-process tool.
True, but they are in the standard library, so they are our
responsibility to fix.
Cheers,
Mark.
Of course, I don't imply that this should be a show stopper or similar,
but it should be taken into consideration along all the other pros and cons.
Regards from cloudy London,
Pablo Galindo Salgado
On Wed, 20 Jan 2021 at 15:12, Mark Shannon <m...@hotpy.org
<mailto:m...@hotpy.org>> wrote:
Hi Pablo,
On 19/01/2021 6:46 pm, Pablo Galindo Salgado wrote:
> Hi Mark,
>
> Thanks for gathering this proposal! Looks very interesting. I
have some preliminary questions: how is this going to affect
> the "py-bt" command of the gdb helpers
(https://github.com/python/cpython/blob/master/Tools/gdb/libpython.py#L1876-L1897)
> and other similar tools that produce a unified Python-C
backtrace? There are several debuggers that
> rely on the fact that they can merge the C stack and the Python
stack by substituting every call to "_PyEval_EvalFrameDefault"
> and friends for the respective Python frame obtained separately
or by inspecting the frame object in the stack (like gdb does).
I don't see any problem fixing up the gdb helpers. The code will
need to
be aware that C frames will be one-to-many to Python frames, but
there's
nothing tricky there.
>
> Is this change going to affect these tools or they will continue
working as before? In case this change will affect this tools,
> is there any workaround to produce the unified C/Python call
stack given the Python stack and the C stack?
It depends on what you mean by "similar tools".
For in-process tools, then the API will continue to work.
For out-of-process debuggers, then the author's are on their own.
But that's always been the case.
The source code is public, and it won't be any more opaque than it
is at
the moment :)
Cheers,
Mark.
>
> Kind regards,
> Pablo Galindo Salgado
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
<mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-le...@python.org
<mailto: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/27DON4D7Y3WMFMOT7OV6D4LD6QUXXQRB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/HHEKGU66A5LZRTQDZWO5627MK5CL37NC/
Code of Conduct: http://python.org/psf/codeofconduct/
