[cjbillington]

To interactively inspect within a function, you could use the debugger with `breakpoint()`. But it's not a regular Python interpreter, which annoys me having to learn the different syntax. You can also embed IPython interactively with:

    import IPython; IPython.embed()

though IPython kinda doesn't clean up after itself, so it's a bit messier (your prompt is messed up afterwards).

Finally, you can:

    import code; code.interact()

The downside of this is there's no history or autocomplete by default.

I have a custom function `embed()` [1] that calls `code.interact()`, but with history and autocomplete configured. This is the closest I got it to looking like a regular Python interpreter at an arbitrary place in the code.

[1] https://pastebin.com/WDuheBfV

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

[radarsat1]

Update: this prompted me to look into it again, it's super easy, if you're running an IPython shell, after an error just type "%debug". Or add "--pdb" to your python-shell-interpreter-args.

https://stackoverflow.com/questions/4234612/launch-an-ipytho...

This gives you a pdb prompt not an IPython prompt, but you can examine local variables where the exception was raised, and exit back to IPython with Ctrl-D.