The bdb module handles basic debugger functions, like setting breakpoints or managing execution via the debugger.
The following exception is defined:
The bdb module also defines two classes:
This class implements temporary breakpoints, ignore counts, disabling and (re-)enabling, and conditionals.
Breakpoints are indexed by number through a list called bpbynumber and by (file, line) pairs through bplist. The former points to a single instance of class Breakpoint. The latter points to a list of such instances since there may be more than one breakpoint per line.
When creating a breakpoint, its associated filename should be in canonical form. If a funcname is defined, a breakpoint hit will be counted when the first line of that function is executed. A conditional breakpoint always counts a hit.
Breakpoint instances have the following methods:
Delete the breakpoint from the list associated to a file/line. If it is the last breakpoint in that position, it also deletes the entry for the file/line.
Mark the breakpoint as enabled.
Mark the breakpoint as disabled.
Print all the information about the breakpoint:
The breakpoint number.
If it is temporary or not.
Its file,line position.
The condition that causes a break.
If it must be ignored the next N times.
The breakpoint hit count.
The Bdb acts as a generic Python debugger base class.
This class takes care of the details of the trace facility; a derived class should implement user interaction. The standard debugger class (pdb.Pdb) is an example.
The following methods of Bdb normally don’t need to be overridden.
Auxiliary method for getting a filename in a canonical form, that is, as a case-normalized (on case-insensitive filesystems) absolute path, stripped of surrounding angle brackets.
Set the botframe, stopframe, returnframe and quitting attributes with values ready to start debugging.
This function is installed as the trace function of debugged frames. Its return value is the new trace function (in most cases, that is, itself).
The default implementation decides how to dispatch a frame, depending on the type of event (passed as a string) that is about to be executed. event can be one of the following:
"line": A new line of code is going to be executed.
"call": A function is about to be called, or another code block entered.
"return": A function or other code block is about to return.
"exception": An exception has occurred.
"c_call": A C function is about to be called.
"c_return": A C function has returned.
"c_exception": A C function has thrown an exception.
For the Python events, specialized functions (see below) are called. For the C events, no action is taken.
The arg parameter depends on the previous event.
For more information on trace functions, see How It Works. For more information on code and frame objects, refer to The standard type hierarchy.
If the debugger should stop on the current line, invoke the user_line() method (which should be overridden in subclasses). Raise a BdbQuit exception if the Bdb.quitting flag is set (which can be set from user_line()). Return a reference to the trace_dispatch() method for further tracing in that scope.
If the debugger should stop on this function call, invoke the user_call() method (which should be overridden in subclasses). Raise a BdbQuit exception if the Bdb.quitting flag is set (which can be set from user_call()). Return a reference to the trace_dispatch() method for further tracing in that scope.
If the debugger should stop on this function return, invoke the user_return() method (which should be overridden in subclasses). Raise a BdbQuit exception if the Bdb.quitting flag is set (which can be set from user_return()). Return a reference to the trace_dispatch() method for further tracing in that scope.
If the debugger should stop at this exception, invokes the user_exception() method (which should be overridden in subclasses). Raise a BdbQuit exception if the Bdb.quitting flag is set (which can be set from user_exception()). Return a reference to the trace_dispatch() method for further tracing in that scope.
Normally derived classes don’t override the following methods, but they may if they want to redefine the definition of stopping and breakpoints.
This method checks if the frame is somewhere below botframe in the call stack. botframe is the frame in which debugging started.
This method checks if there is a breakpoint in the filename and line belonging to frame or, at least, in the current function. If the breakpoint is a temporary one, this method deletes it.
This method checks if there is a breakpoint in the filename of the current frame.
Derived classes should override these methods to gain control over debugger operation.
This method is called from dispatch_call() when there is the possibility that a break might be necessary anywhere inside the called function.
This method is called from dispatch_line() when either stop_here() or break_here() yields True.
This method is called from dispatch_return() when stop_here() yields True.
This method is called from dispatch_exception() when stop_here() yields True.
Handle how a breakpoint must be removed when it is a temporary one.
This method must be implemented by derived classes.
Derived classes and clients can call the following methods to affect the stepping state.
Stop after one line of code.
Stop on the next line in or below the given frame.
Stop when returning from the given frame.
Start debugging from frame. If frame is not specified, debugging starts from caller’s frame.
Stop only at breakpoints or when finished. If there are no breakpoints, set the system trace function to None.
Set the quitting attribute to True. This raises BdbQuit in the next call to one of the dispatch_*() methods.
Derived classes and clients can call the following methods to manipulate breakpoints. These methods return a string containing an error message if something went wrong, or None if all is well.
Set a new breakpoint. If the lineno line doesn’t exist for the filename passed as argument, return an error message. The filename should be in canonical form, as described in the canonic() method.
Delete the breakpoints in filename and lineno. If none were set, an error message is returned.
Delete the breakpoint which has the index arg in the Breakpoint.bpbynumber. If arg is not numeric or out of range, return an error message.
Delete all breakpoints in filename. If none were set, an error message is returned.
Delete all existing breakpoints.
Check if there is a breakpoint for lineno of filename.
Return all breakpoints for lineno in filename, or an empty list if none are set.
Return all breakpoints in filename, or an empty list if none are set.
Return all breakpoints that are set.
Derived classes and clients can call the following methods to get a data structure representing a stack trace.
Get a list of records for a frame and all higher (calling) and lower frames, and the size of the higher part.
Return a string with information about a stack entry, identified by a (frame, lineno) tuple:
The canonical form of the filename which contains the frame.
The function name, or "<lambda>".
The input arguments.
The return value.
The line of code (if it exists).
The following two methods can be called by clients to use a debugger to debug a statement, given as a string.
Debug a statement executed via the exec statement. globals defaults to __main__.__dict__, locals defaults to globals.
Debug an expression executed via the eval() function. globals and locals have the same meaning as in run().
Debug a single function call, and return its result.
Finally, the module defines the following functions:
Check whether we should break here, depending on the way the breakpoint b was set.
If it was set via line number, it checks if b.line is the same as the one in the frame also passed as argument. If the breakpoint was set via function name, we have to check we are in the right frame (the right function) and if we are in its first executable line.
Determine if there is an effective (active) breakpoint at this line of code. Return breakpoint number or 0 if none.
Called only if we know there is a breakpoint at this location. Returns the breakpoint that was triggered and a flag that indicates if it is ok to delete a temporary breakpoint.
关于本评注系统
本站使用上下文关联的评注系统来收集反馈信息。不同于一般对整章做评注的做法, 我们允许你对每一个独立的“文本块”做评注。一个“文本块”看起来是这样的:
一个“文本块”是一个段落,一个列表项,一段代码,或者其他一小段内容。 你选中它会高亮度显示:
要对文本块做评注,你只需要点击它旁边的标识块:
我们会仔细阅读每个评论,如果可能的话我们也会把评注考虑到未来的版本中去:
如果你愿意你的评注被采用,请确保留下你的全名 (注意不是昵称或简称)
Many, many thanks to Jack Slocum; the inspiration and much of the code for the comment system comes from Jack's blog, and this site couldn't have been built without his wonderful
YAHOO.extlibrary. Thanks also to Yahoo for YUI itself.