I recently built a debugger for the Win32 GUI version, by subclassing pdb.
Unfortunately, I am a little hazy (both about what I did, and exactly how
pdb works anyway!).
> I want to be able to route embedded calls to the debugger
> if a switch is set, but return the result to the caller,
> so it can continue. I can do it now, by:
This is a nice feature, and something my debugger could use too.
Now, I _think_ the following _may_ work.
Python has a sys variable (or a builtin - gee I wish I had my sources handy
for reference) for the debugger. As far as I can remember, all pdb really
does is to set this tracer function to the debugger, then execute the call.
What you may be able to do is to simply set Python's tracer variable to
your debugger, and possibly set a pdb internal state variable. There should
not really be any need to wrap the call itself in a debugger call. Note,
however, that the debugger will return a pdb.break exception when the user
cancels it.
I havent played with this, but I did notice the following. My app has
something like:
>Python code: CreateWindow
---> C++ code: Does the create window
---> OS Window Creation - calls OnCreateClient()
---> C++ code: Sees OnCreateClient callback,
and calls Python method.
---> Python code: OnCreateClient, and returns
---> OS Window creation returns
---> C++ CreateWindow returns
>Python CreateWindow returns
Now, if I execute the initial CreateWindow in the debugger context, my
Python OnCreateClient callback is also executed under the debugger. This
happens even though the CreateWindow() call has yet to return, and the
OnCreateClient code is executed "normally" - ie, no special case for
debugger.
This seems to work because the Python tracer hook has been installed to the
debugger - ie, actually doing a pdb.call() type invocation seems not to be
necessary, just that the tracer hook is set.
I hope this makes some sense...
Regards,
Mark.