Dave Malcolm added the comment:
On Tue, 2010-11-02 at 17:25 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <[email protected]> added the comment:
>
> I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to
> support this. Also, why do you allow any arguments to sys._breakpoint()?
Agreed about _Py_BREAKPOINT.
The reason for allowing arguments to sys._breakpoint() is so that the
developer can pass in arbitrary objects (or collections of objects),
which can then be easily inspected from the debugger. Does that seem
sane?
Maybe the docs should read:
------
This may be of use when tracking down bugs: the breakpoint can be
guarded by Python-level conditionals, and supply Python-generated data::
if foo and bar and not baz:
sys._breakpoint(some_func(foo, bar, baz))
In the above example, if the given python conditional holds (and no
exception is raised calling "some_func"), execution will halt under
the debugger within Python/sysmodule.c:sys_breakpoint, and the result of
some_func() will be inspectable in the debugger as
((PyTupleObject*)args)[0]
static PyObject *
sys_breakpoint(PyObject *self, PyObject *args)
{
_Py_BREAKPOINT();
Py_RETURN_NONE;
}
It can also be useful to call when debugging the CPython interpreter: if
you add a call to this function immediately before the code of interest,
you can step out of sys_breakpoint and then step through subsequent
execution.
------
I thought about it making it METH_O instead (to make it easier to look
at a single object), but then you'd be forced to pass an object in when
using it, I think (though None should work).
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue9635>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
