> Do you have any specific examples? >From my previous message: gdb helpers, lldb helpers, TotalView debugger, py-spy and I know of at least 3 closed source tools.
>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. The responsibility to fix it is on the authors, yes, but is not that back and white. In the worst case, what users will see is that tools that worked now don't and in the worst-worst case users will see that those tools will not work again because is virtually impossible with the new system. And that, as I said is not a show stopper, but it matters. In any case, if we are able to fix the gdb helpers in the stdlib, then I am not afraid because it means that everyone could fix their own thing. Cheers, Pablo Galindo Salgado On Wed, 20 Jan 2021 at 16:06, Mark Shannon <m...@hotpy.org> wrote: > 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/BZPUB2Y445X36L24CPSNHQBU3BQEDXXZ/ Code of Conduct: http://python.org/psf/codeofconduct/
