> 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).

I don't like this API. I really prefer METH_O because it is already very difficult to dump a Python object in a debugger (especially with gdb macros). Why not using two functions? One without argument, One with an argument.

The sys module is maybe not the right place for such low level function. You may create a new module with a name starting with _ (ex: _python_dbg). I'm quite sure that you will find other nice functions to add if you have a module dedicated to debugging :-)

If you don't want to create a new module, faulthandler might be used to add new debug functions.

It's maybe unrelated, but Brian Curtin also created a module to help debugging with Visual Studio:
https://bitbucket.org/briancurtin/minidumper/

We may use the same module for all debugging functions? (I suppose that Brian Curtin wants to integrate its minidumper into Python 3.4.)

Example:

 * faulthandler._breakpoint()
 * faulthandler._inspect(obj) # breakpoint with an object
 * faulthandler.enable_minidumper(...)
 * faulthandler.disable_minidumper(...)

--

For Power PC, the machine code to generate a breakpoint is 0x0cc00000. The instruction looks to be called twllei. Something like: "twllei reg_ZERO,trap_Cerror". Hum, it looks like there is family of instructions related to trap: all TW* instructions (twle, twlt, twge, ...).