Can anyone recommend a video/series on Python debugging? Debugging has been my greatest struggle with getting into development. I get frustrated and spend over a day on simple scripts
Guide to Python Debugging
131–140 of 149 posts
Re: Guide to Python Debugging
#132This 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.
I'm on the second camp of that divide as well. Most times, all you really need is the logging functionality (whether you get it from a logger or a debugger) to observe the outcome of an action. It's not really necessary to witness unfolding before your eyes the step-by-step playbook of how a variable came to acquire the wrong value. It's enough to see that it got the wrong value and from there you can infer what the problem is and the corrections to apply. That's most times.
However, some intricate situations are better suited for the debugger (flags set in inner loops, circuitous algorithms, values unknowingly inherited, values mistakenly overridden, etc). In those it usually is harder to reason about the flow of the logic. In my experience that's where a debugger shines, as it shows you what the code is doing. But even then and with enough experience and instinct, you can get by with just logging a value and reading the code.
Some renown programmers on how they don't use debuggers: L. Torvalds: https://lwn.net/2000/0914/a/lt-debugger.php3 J.G. Cunningham: https://blog.jgc.org/2007/01/tao-of-debugging.html Robert C. Martin: https://www.artima.com/weblogs/viewpost.jsp?thread=23476
Re: Guide to Python Debugging
#133This is buried in the comments but `pudb` is great debugger: https://pypi.org/project/pudb/ - visual interface to set breakpoint - inline interpreter - inspect on exception It's like using a modern debugger but inside your console. Can't recommend enough.
Does it support multi-threaded python code?
Looks like it does: https://medium.com/@auro_227/use-pudb-to-debug-python-multip...
Re: Guide to Python Debugging
#134I've been a Python developer for more than ten years. Approximately 98% of the time I need to debug something I use print() statements and this: import IPython; IPython.embed()
This has been my go-to debug method for years now. Find a critical section of code, drop the embed call there (with maybe a print statement or two leading up to it for context).
For stepping through code, I agree with your other comments that it is often too much for debugging. To recreate it when really necessary, I might sprinkle a handful of embed calls
Re: Guide to Python Debugging
#135Earlier 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…
Btw, this is exactly this feature request: https://youtrack.jetbrains.com/issue/IDEA-226455 Current statement: > We're very aware of how important this feature is, and we have several initiatives in place to provide a great experience for fully remote development. Unfortunately, at this time we're unable to share any specifics or timeframes, as getting the best possible experience requires massive-scale architectural…
Glad to know I'm not the only one. I still have the issue but I do still use pycharm (I do docker local and then just go from there - but my preferred was always basically "remote" develop - I used to use that so if I was on my laptop or desktop etc I was always on the same (linux) machine even if coming in from mac or windows.
Re: Guide to Python Debugging
#136Earlier 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…
My one current gripe about PyCharm is its seemingly lack of support for git submodules. As in I don't see any way to do a pull or push or work with branches on a submodule. I resort to doing all of my git work on the command line (which I don't mind - it's how I learned to work with git from the beginning).
Re: Guide to Python Debugging
#137Earlier 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…
Btw, this is exactly this feature request: https://youtrack.jetbrains.com/issue/IDEA-226455 Current statement: > We're very aware of how important this feature is, and we have several initiatives in place to provide a great experience for fully remote development. Unfortunately, at this time we're unable to share any specifics or timeframes, as getting the best possible experience requires massive-scale architectural…
Thanks for that link. Glad to see that it is prioritized on their roadmap, and also to know that there is no point in my trying to work around their current implementation because it seems it just won't work the way vscode can work seamlessly.
Re: Guide to Python Debugging
#138Earlier quoted context omitted.
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.
I'm on the second camp of that divide as well. Most times, all you really need is the logging functionality (whether you get it from a logger or a debugger) to observe the outcome of an action. It's not really necessary to witness unfolding before your eyes the step-by-step playbook of how a variable came to acquire the wrong value. It's enough to see that it got the wrong value and from there you can infer what the…
On my own code I don't need debuggers, that is the scenario that Linus is talking about -- is Robert C. Martin a renowned programmer? :-)
For other people's Python code, especially if they mistakenly think that Python is Haskell, I do need a debugger. I've seen "scientific" Python code that is iterators all the way down and can only be understood by running the program.
Of course no actual science is being done with such programs, but that doesn't seem to matter.
Re: Guide to Python Debugging
#139This 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).
PyCharm is an open-core editor. The FOSS edition is a second-class citizen. I make a
point not to run any proprietary software on my machine besides occasional
whitelisted JS, firmware, and patent-encumbered media codecs (which still have free
implementations).
Neovim's master branch has a built-in Language Server Protocol client and Treesitter implementation, both of which have pre-made configs for Python development. Jumping between symbols, viewing floating documentation/signatures/git-blame, asynchronous completion, diagnostics, etc. are all readily available with a fraction of the battery/CPU/memory usage on a fully-FOSS platform that works on even more platforms (BSD, over SSH, etc). Jumping between symbols and listing usage of an object in a project with hundreds of files has never been faster. All this starts up in milliseconds. Being able to use an editor advanced enoguh for a large project but lightweight enough to launch with a keybind just to write the HN comment is amazing.
Here are some screenshots of the LSP and treesitter in action:
Floating documentation and diagnostics: https://i.imgur.com/0TYi5en.png
A small taste of Treesitter's highlighting + navigation features: https://i.imgur.com/wrSpJ2X.png
Completion from the nvim-lsp source: https://i.imgur.com/CzAAJuC.png
Neovim also has FZF integration to fuzzy-search thousands of symbols, files, reference, etc. Since it's the same FZF that I use everywhere else underneath, the interface is quite familiar.
TLDR: Neovim is a lightweight text editor that integrates with external tools to transform itself into an IDE.
Re: Guide to Python Debugging
#140Earlier 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
This seems to be a decent intro. It's focused on pycharm but the same functionality is available in VS Code and most other IDEs.