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

91–100 of 149 posts

Re: Guide to Python Debugging

#91

Post by 3pt14159 »

Here's my list of helpful additions:

1. https://pypi.org/project/pdbpp/

This is basically a better version of pdb.

2. ~/.pdbrc

Useful for common commands that you would otherwise have to type out. For example, if you do TDD on a JSON API and often need to debug the output consider this alias:

    alias ppr pp response.json()
3. ~/.pdbrc.py

This file loads before pdb starts, so it lets you customize it a bit and add things like history. Here is a simple version to get you started:

https://gist.github.com/zachaysan/25712f3e9aa02a234437f89c60...

Re: Guide to Python Debugging

#92

Post by darkteflon »

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

I have the same use case as you and went through exactly this. I ended up feeling that Pycharm’s implementation wasn’t really a suitable solution. Some others had mentioned the alternative of mounting the remote filesystem locally using SSHFS but I found that this created issues of its own. In the end I settled on using Syncthing to sync all of my folders and then just run a local instance of Pycharm (and VS Code) at either end (Ubuntu 20 desktop and Macbook Pro). I’m very happy with this setup so far and would happily recommend it.

Re: Guide to Python Debugging

#93

Post by JackC »

themoops36 wrote: post #86
soVeryTired wrote: post #70

Earlier quoted context omitted.

I work with data scientists and ML people more than hardcore developers, but I've noticed that a lot of people who use sublime text tend to resort to print() debugging. IMO python's lack of explicit typing makes it difficult to reason about by inspection alone ("does foo() return a dataframe or a numpy array?!"). For me at least, I need to get into the guts of a system and watch it execute to really understand it. Th…

Can you recommend anything to learn debugging the proper way (or maybe the article here is a good resource)? I might be one of these print() people- usually when I hit bugs I read through the stack trace and can figure it out, but if it's more of an "unexpected result" I resort to print() so I know exactly what I'm doing. Would love to learn a more efficient way

For me the next step after print debugging was adding an `import pdb; pdb.set_trace()` shortcut to my editor (I use "pdb" as the shortcut, but whatever works.) Do that whenever you would add a print statement and re-run to resolve a confusing bug. It drops you into a REPL at that point in the code, and you can then print values and try running things. It basically just collapses a series of "add print statement and run" into a much tighter loop, which can save a ton of time depending how long it takes your program to throw the error and how many print statements it was going to take you to figure out what was wrong.

Key commands I use while in pdb: ? for help; n to run the next line; s to step into the next function call; w to see where I am in the stack; u and d to go up and down the stack; unt to run until a new line is reached (if you're stuck in a loop); interact to go to a normal python shell (if the pdb shell is confused by what you typed).

This won't replace print statements 100% of the time, because it might be simpler to print a bunch of logs to see where the problem is than to step through the program in the debugger; use it when you know where the problem probably is but not what it is.

Re: Guide to Python Debugging

#94

Post by jpitz »

mixmastamyk wrote: post #14
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).

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.

I do data engineering and lots of systems scripting and Dev ops in python. I write in emacs and find I rarely if ever need a debugger.

Re: Guide to Python Debugging

#95

Post by phyrex »

nwatson wrote: post #71
AlexPl292 wrote: post #28

Earlier quoted context omitted.

Could you please describe some cases?

PyCharm is a huge help when dealing with APIs that return huge or complicated data structures or where documentation is vague. Examples: interacting with AWS with boto3; interacting with Kubernetes. You can read the docs alone, but much better is to set up a live interaction with the API. I set a breakpoint and explore the returned data structure in the debugger. All types and content are clearly visible and are a gu…

You're discovering REPL-based development ;)

Re: Guide to Python Debugging

#96

Post by david_draco »

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

There is a divide: Some people love debuggers, some people think placing print statements is the best way to debug code. You are reading an article from the second camp.

Log files have the benefit of being able to adjust the signal-to-noise afterwards, I guess that is why it is highlighted.

Re: Guide to Python Debugging

#97

Post by zo1 »

pjmlp wrote: post #80
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).

VSCode and Visual Studio have first class support for Python. https://visualstudio.microsoft.com/vs/features/python/ https://code.visualstudio.com/docs/python/python-tutorial Both include quite capable debuggers, and AI powered code completion, intelicode. https://marketplace.visualstudio.com/items?itemName=VisualSt...

I've tried it, and watched many a colleague "struggle" with it. "First class" is definitely an over-statement from my perspective, even if it might be great compared to what you'd get with plain-text editors. It's type-hinting half the time behaves oddly even with type-hinting present.

But it is getting better, that's for sure. Looking forward to see upcoming iterations.

Re: Guide to Python Debugging

#98

Post by msluyter »

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

re: 3, for me another killer feature is syntactically aware selection (alt-up/alt-down). Whatever symbol you're on, alt-up will select increasingly large scopes: symbol -> expression(s) -> statement(s) -> method/function(s) -> class -> file. I feel pretty crippled without it.

Re: Guide to Python Debugging

#100

Post by kikoreis »

It misses the most important one-liner for python debugging:

  import pdb; pdb.set_trace()
which leaves you in the debugger at a specific point in your code. When I actually did Python dev rare was the day I didn't crack that out!
Post reply on HN