This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kevinbutler
Recipients
Date 2003-09-20.19:52:13
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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

History
Date User Action Args
2007-08-23 15:29:12adminlinkissue809887 messages
2007-08-23 15:29:12admincreate