Ed Blackman <e...@edgewood.to> writes:
> I've recently started using Python for my job (as opposed to writing
> smallish scripts for personal use), and so have needed to debug quite
> a bit more.
>
> I've been using pdb mainly via 'python -m pdb script args'. Perhaps
> it's my Java background, but even when I have permissions to change
> the source, I find editing source to insert 'import pdb;
> pdb.set_trace()' unnatural. The consequence is that I have to
> recreate my breakpoints when I have to exit pdb.
>
> I've written the following code, which I load from .pdbrc with
> 'execfile(os.path.expanduser('~/.pydb.py'))'
This approach does not seem very robust to me:
"pdb" resolves all breakpoints to lines (in source files) - and
any modification to the source may change the lines.
As a consequence, your breakpoints may no longer be at the
places where you expect them.
A long time ago, I have developped "dm.pdb" - a slight
extension/improvement over "pdb". One of the extensions
has been to make it possible to set breakpoints from outside
the debugger -- without too many surprises. It looks somehow like that:
from dm.pdb import Pdb; D = Pdb()
...
from ... import f
from ... import g
from ... import C
...
D.do_break("f") # set breakpoint on "f"
D.do_break("g") # set breakpoint on "g"
D.do_breack("C.m") # set breakpoint on method "m" of class "C"
...
D.run("...")
It is more robust than breakpoints on line numbers - but, of course,
it cannot be automated but must be targeted to individual programs.
In addition, the robustness is limited to breakpoints on
executable objects; setting breakpoints on line numbers is possible, too --
but has the same problem with moving lines.
In the meantime, "pdb" itself may support this form of external
control (maybe even better then "dm.pdb").
--
https://mail.python.org/mailman/listinfo/python-list
