>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. Notice as well that the gdb helpers *are* an out-of-process tool. 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> 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 > > 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/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/IZNCDQCYPATMZRU7SHQM4OTMVXUI6VX5/ Code of Conduct: http://python.org/psf/codeofconduct/
