Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to Python Debugging

martinheinz.dev

Post reply on HN
Print view View original

11–20 of 149 posts

Re: Guide to Python Debugging

#11

Post by ed25519FUUU »

Don't forget breakpoints! Learn how to move around in the debugger, it will be a LIFESAVER.

Above a troublesome line of code, drop this line:

    import pdb; pdb.set_trace()
And run it as normally. Now you can explore. Drop into the function, step forward, go up. You just need to learn to move around. With pdb you can really explore what's going on.

Re: Guide to Python Debugging

#12

Post by sooheon »

_coveredInBees wrote: post #7
abiogenesis wrote: post #4

Earlier quoted context omitted.

I second PyCharm, not only from a debugging perspective but as a whole. I don't understand people struggling with generic text editors, development oriented text tools (sublime etc), or even vscode just because they are free when there is a much better tool money can buy (and PyCharm has a free, community version as well).

My main reason for wishing to be able to switch to Vscode instead of Pycharm is because vscode's remote development UX is really really nice and works a lot better for me compared to the Pycharm way of SFTP-ing files between your local and the remote. My use-case where Pycharm feels a bit deficient is that I have an Ubuntu deeplearning box at work that I can VNC into and develop on whenever needed. I have all my repo…

> vscode's remote development UX is really really nice

I'm very interested in this, so looked it up.

For your use case, I think it's just a matter of setting the correct Deployment Mappings. There's a setting when you're creating the remote interpreter to specify your own mapped directory (not the default /tmp/pycharm-foo) and a checkbox to not have it automatically upload what you have on your local machine (since in your case the source of truth is the remote). Then you can manually sync the diffs yourself with pycharm or git.

Your workflow's interesting in that the remote machine is the main and your laptop's the satellite, and pycharm's model has it the other way around.

Also, if you've already got the interpreter set up, you can just change the deployment mapping settings.

Re: Guide to Python Debugging

#14

Post by mixmastamyk »

abiogenesis wrote: post #4
_coveredInBees wrote: post #3

This is a bit of a weird article. It spends most of the time talking about logging, which is somewhat useful for debugging but not really. pdb gets a few lines of description, and that is about it. Personally, I can't live without Pycharm when working with Python purely because of how fantastic the debugging experience is. The integration with the interactive IPython shell is simply fantastic, and the live variable v…

I second PyCharm, not only from a debugging perspective but as a whole. I don't understand people struggling with generic text editors, development oriented text tools (sublime etc), or even vscode just because they are free when there is a much better tool money can buy (and PyCharm has a free, community version as well).

I write Python with an enhanced text editor every day and don't struggle in the slightest. It's lightening quick as well. I pull out a proper debugger about twice a year.

Re: Guide to Python Debugging

#15

Post by markus_zhang »

_coveredInBees wrote: post #10
thomk wrote: post #6

Earlier quoted context omitted.

I'm a vscode user and I do like it. I only really use it for the file navigation and color coding though. Autocomplete drives me nuts, so I turned that off completely. I am a pdb fan so i drop in to that when needed. I never really considered PyCharm to be honest, it feels like overkill for me. However your allegiance sounds interesting. Can you give some reasons why you like it so much?

Not the person you replied to, but I love vscode from when I did a bunch of React + JS stuff a few years back. I also do a ton of software development and machine learning work in Python now and have never managed to move away from Pycharm even though I'd love to be able to have a good enough experience in Vscode so that I could make the switch from Pycharm (the remote development experience in vscode is really neat…

Agreed to every point.

Pycharm really shocked me by correctly suggesting most of library related stuffs as ling as I type hint them.

I really enjoyed pycharm and datagrip and wondering how does clion compare with vs.

Re: Guide to Python Debugging

#16

Post by _coveredInBees »

sooheon wrote: post #12
_coveredInBees wrote: post #7

Earlier quoted context omitted.

My main reason for wishing to be able to switch to Vscode instead of Pycharm is because vscode's remote development UX is really really nice and works a lot better for me compared to the Pycharm way of SFTP-ing files between your local and the remote. My use-case where Pycharm feels a bit deficient is that I have an Ubuntu deeplearning box at work that I can VNC into and develop on whenever needed. I have all my repo…

> vscode's remote development UX is really really nice I'm very interested in this, so looked it up. For your use case, I think it's just a matter of setting the correct Deployment Mappings. There's a setting when you're creating the remote interpreter to specify your own mapped directory (not the default /tmp/pycharm-foo) and a checkbox to not have it automatically upload what you have on your local machine (since i…

Thanks for taking the time to look into this. I'll give this a shot again when I have a bit of time to tinker with this.

Re: Guide to Python Debugging

#17

Post by ngcc_hk »

_coveredInBees wrote: post #16
sooheon wrote: post #12

Earlier quoted context omitted.

> vscode's remote development UX is really really nice I'm very interested in this, so looked it up. For your use case, I think it's just a matter of setting the correct Deployment Mappings. There's a setting when you're creating the remote interpreter to specify your own mapped directory (not the default /tmp/pycharm-foo) and a checkbox to not have it automatically upload what you have on your local machine (since i…

Thanks for taking the time to look into this. I'll give this a shot again when I have a bit of time to tinker with this.

Thanks as well. Help people like me who walks by.

Re: Guide to Python Debugging

#18

Post by karlicoss »

ed25519FUUU wrote: post #11

Don't forget breakpoints! Learn how to move around in the debugger, it will be a LIFESAVER. Above a troublesome line of code, drop this line: import pdb; pdb.set_trace() And run it as normally. Now you can explore. Drop into the function, step forward, go up. You just need to learn to move around. With pdb you can really explore what's going on.

Or even just breakpoint() built-in in python 3.7+ In addition you can set PYTHONBREAKPOINT=ipdb.set_trace (or whatever you prefer) in your shell rc file

Re: Guide to Python Debugging

#19

Post by saagarjha »

When debugging compiled code, I often attach a debugger to the process after it’s started to introspect it. I’ve often wanted to do something similar in Python; does anyone know of a tool that might do something like this?

Re: Guide to Python Debugging

#20

Post by walty8 »

saagarjha wrote: post #19

When debugging compiled code, I often attach a debugger to the process after it’s started to introspect it. I’ve often wanted to do something similar in Python; does anyone know of a tool that might do something like this?

may be python pdb?

https://docs.python.org/3/library/pdb.html

Post reply on HN