On Tue, 2010-11-02 at 17:25 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> 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).