views:

129

answers:

2

I'm calling python -m pdb myapp.py, when an exception fires, and I'd normally be thrown back to the pdb interpreter to investigate the problem. However this exception is being thrown after I've called through curses.wrapper() and entered curses mode, rendering the pdb interpreter useless. How can I work around this?

+4  A: 

Not being familiar with Python, this may not be exactly what you want. But apparently, winpdb can attach to a script - just like gdb can to a running process (IIUC).

http://winpdb.org/docs/launch-time/

Don't be mislead by the name, it is platform independent.

James Morris
Good suggestion. You beat me to this. It would be the right way to go about this problem. Also useful for GUIs and daemon processes.
Noufal Ibrahim
I'd forgotten all about it!
James Morris
I don't suppose it's possible to attach using the core library's pdb?
Matt Joiner
I don't think so. You'll need to use winpdb on the 'client' and the 'server'.
Noufal Ibrahim
+2  A: 

James` answer is a good and I've upvoted it but I'd also consider trying to split the logic and presentation layers of my program. Keep the curses part a thin layer on top of a library and write a simple driver that invokes the correct routines to recreate the error. Then you can dive in and do what's necessary.

Another way I can think of is to create a function called debug or something that throws you back into the regular screen and invokes pdb. Then stick it just before the code that raises the exception and run your program. Something like

def debug(stdscr):
    curses.nocbreak()
    stdscr.keypad(0)
    curses.echo()
    curses.endwin()
    import pdb; pdb.set_trace()

Apparently, this is similar to what is done with the curses.wrapper function. It's mentioned briefly at http://www.amk.ca/python/howto/curses/.

Noufal Ibrahim
A wise suggestion to keep the curses logic separated, and thanks for the `curses.wrapper` pointer.
Matt Joiner
You're welcome.
Noufal Ibrahim