Author dmalcolm
Recipients dmalcolm, loewis, pitrou, vstinner
Date 2012-08-07.16:17:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1344356212.24650.14.camel@surprise>
In-reply-to <>
On Tue, 2010-11-02 at 17:25 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <> 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

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

   static PyObject *
   sys_breakpoint(PyObject *self, PyObject *args)

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

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).
Date User Action Args
2012-08-07 16:17:28dmalcolmsetrecipients: + dmalcolm, loewis, pitrou, vstinner
2012-08-07 16:17:27dmalcolmlinkissue9635 messages
2012-08-07 16:17:25dmalcolmcreate