[radarsat1]

Thank you! I didn't know about code.interact, but IPython.embed I have used in the past. My point was more that I would like a way to drop to an IPython prompt when my program crashes, I really don't like the solution of having to modify the code to insert a statement where I think my program is going to crash.

In any case I think there was a way to examine variables from up the stack of a stack trace or something like that.. bit too lazy to look it up right now. Regardless, working with a REPL in emacs is pretty great ;)

I think there is a way to do jupyter from emacs (or at least there was a way to do ipython notebooks), but I haven't used it extensively, just tested it once I think. I guess I'm pretty satisfied with the REPL and haven't found a need to have intermediate output during the running of a program.

What I do like about the matpotlib interactive approach is being able to watch the progress of a loop very easily, which is hard to do from a notebook, although there are some ways, but they are either hacky or require some pretty sophisticated things like custom widgets.

[cjbillington]

Yeah I considered extending it to automatically pop into the frame where the exception happened, but this is actually not as useful as it sounds, since the exception is usually much deeper in some other library and not in your code where you actually want to inspect variables. You would either need to declare the boundary between 'your' code and other code (by filepath or something), so the tool could know where it should run, or you would need to include commands to push and pop through the stack, which complicates things a bit and is on the path to a full debugger (so perhaps one should just use the debugger - as you've mentioned in the sibling comment).

So I just add a try: except around code known to be crashing and call my `embed()` function on except. This has served me well enough that I haven't bothered with anything else.

Plus, if I really want to inspect unplanned crashes, I would want to be able to get them when running, and not just developing, the app. So there might not even be a terminal - there are more complications than just 'not having to declare where you think it will crash', so I don't think I'll bother solving the more specific problem unless it would help me debug unexpected crashes in a broader context.