TheSaint <[EMAIL PROTECTED]> writes: > On 19:21, venerdì 13 giugno 2008 R. Bernstein wrote: > >> I'm not completely sure what you mean, but I gather that in >> post-mortem debugging you'd like to inspect local variables defined at the >> place of error. > > Yes, exactly. This can be seen with pdb, but not pydb. > If I'm testing a piece of code and it breaks, then I'd like to see the > variables and find which of them doesn't go as expected. > >> Python as a language is a little different than say Ruby. In Python >> the handler for the exception is called *after* the stack is unwound > > I'm not doing comparison with other languages. I'm simply curious to know why > pydb don't keep variables like pdb.
If you are simply curious, then a guess is that the frame from the traceback (t) isn't set by pydb's post_mortem method in calling the Pdb interaction() method, whereas it does get set in the corresponding pdb post_mortem code. It's possible this is a bug -- it's all in the details. But if it is a bug or a feature improvement, probably a better place to to request a change would be in the tracker for the pydb project: http://sourceforge.net/tracker/?group_id=61395 Should you go this route, I'd suggest giving the smallest program and scenario that exhibits the problem but also has a different behavior in pdb. There are programming interfaces to post-mortem debugging in pdb and pydb, namely post_mortem() and pm(); so best is a short self contained program that when run sets up as much of this as possible. And if the bug is accepted and fixed such a short-self contained program would get turned into a test case and incluide to the set regression tests normally run. > > Final, I agreed the idea to restart the debugger when an exception is trow. > It could be feasible to let reload the file and restart. Some time I can > re-run the program , as the error is fixed, but sometime pdb doesn't > recognize the corrections applied. The restart that I submitted as a patch to pdb two and a half years ago is what I call a "warm" restart: no Python code is actually reloaded. The reason ti was done way is that is a simple way to maintain the debugger settings such as breakpoints; also it requires saving less knowledge about how the program was initially run so it might be applicable in more contexts. The down side though, in addition to what you've noticed with regards to files which have changed, is that global state may be different going into the program when it is restarted. In the last pydb release, 1.23 a "save" command was added to so that breakpoints and other debugger state could be saved across debug sessions which includes a "cold" or "exec" restart. > I mean that after a post-mortem event, the debugger should forget all > variables and reload the program, which meanwhile could be debugged. > > -- > Mailsweeper Home : http://it.geocities.com/call_me_not_now/index.html -- http://mail.python.org/mailman/listinfo/python-list
