Live data from Hacker News

Jupyter notebooks in the IDE: VS Code vs. PyCharm

towardsdatascience.com

61–62 of 62 posts

Re: Jupyter notebooks in the IDE: VS Code vs. PyCharm

#61

Earlier quoted context omitted.

I haven't even gotten into org mode, I just edit Python using emacs and it works great. I can evaluate parts of the code and jump to the interpreter when needed. I keep a matplotlib window open with plt.ion() when running locally, or use plt.savefig() when running remotely and have a qiv window open that automatically detects new images. Works great. The only thing I would like is to be able to use the Python interpr…

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.int…

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.

Re: Jupyter notebooks in the IDE: VS Code vs. PyCharm

#62

Earlier quoted context omitted.

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.int…

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 li…

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.

Post reply on HN