Message44666
pdb was inconsistent in reporting changes to
breakpoints, reporting 'Deleted breakpoint #' in one
case, and not reporting the deletion in another.
This patch makes pdb consistently report
"Deleted/disabled/enabled breakpoint # at PATH:#"
for deleting, enabling, or disabling a breakpoint.
This makes it easier to integrate with IDEs such as
emacs gud mode (see discussion on python-dev startig
with
http://mail.python.org/pipermail/python-dev/2003-September/038147.html
).
Potential items for concern:
- I completely replaced the Bdb.get_break method. It
was returning a boolean indicating if the breakpoint
existed or not, which appeared to be an error
(get_breaks returned the list of breakpoints). The
method was never used in bdb.py or pdb.py, so I
replaced it with what I thought it should be. :-)
That is, it now returns the breakpoint instance
requested. If there is a reason, I can easily make
this a new method
(get_breakpoint/get_breakpointinstance) rather than
replacing get_break.
- I've duplicated logic from Bdb.clear_bpbynumber into
a new method get_bpbynumber. The logic differs only in
the return error messages or None. This seemed the
simplest way to preserve the return value semantics
convention of the Bdb class.
- I'm also calling 'get', then 'clear' which does the
work of 'get' twice. I did this to preserve the return
value conventions of Bdb and make the breakpoint info
available to the UI. Shouldn't be a performance issue,
right? ;-)
I believe this could go into 2.3.* and 2.4
|
|
Date |
User |
Action |
Args |
2007-08-23 15:29:12 | admin | link | issue809887 messages |
2007-08-23 15:29:12 | admin | create | |
|