Guide to Python Debugging
martinheinz.dev
martinheinz.dev
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 viewer is also really handy. Between being able to prototype code in the interactive IPython REPL and then graduate it seamlessly to scripts/functions/classes, and then having an amazing debugging UX to fallback on for those bugs that slip through, I find myself to be orders of magnitude more efficient than when coding in something like vscode (which I absolutely love, and want to transition to for Python coding, but it is extremely limited in comparison to Pycharm, especially when it comes to the REPL experience + debugging).
I also think there's something to it being forced to think about your code rather than just relying on your IDE. In the past I saw random functions getting extracted to random modules and imported everywhere because PyCharm makes it so easy to do so, with no real thought as to where it belongs, which led to some weird circular import error happening pretty much every month.
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. The print() debug crowd tend to be much better than me at reasoning about code by inspection alone, but when you work on something complex that you didn't write yourself, that only gets you so far.
That doesn't work great on other people's code, obviously.
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
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.
I do tend to reach for a simple log first though. I find it's ofte quicker to place a bunch of log statments than step through every statment. The debugger comes out for more complex issues.
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 repos cloned locally and work on various projects locally (and Pycharm is my IDE of choice on the Ubuntu box). But when I work from home, VNC feels a bit too sluggish and remote development would be much better for me. The vscode experience is pretty fantastic. I can setup SSH access to my box and have an open project for the same repos that I have cloned locally on my Ubuntu box and it's as if I am working on it natively. Everything is super snappy and even my bash sessions have the correct remote venvs activated correctly.
In contrast, every time I tried mimicking this in Pycharm (the paid version), it seemed like there was no way to link my already cloned repos on the Ubuntu box to my local version on my laptop so that work I did locally would always also be "live" on my Ubuntu box so that were I to VNC into my Ubuntu box and open the same project in my local Pycharm IDE, it would exactly mirror the state of my Pycharm IDE on my laptop. Is what I want possible? Everything I tried seem to result in my laptop Pycharm setting up a new project somewhere on my Ubuntu box where it would SFTP my project files to, but that resulted in a duplicate of my repo in some other location, which is not what I want. Hopefully this made sense?
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.
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 changes to our codebase, but we've been working on this for quite some time already and we believe that we will have a solution that will go above and beyond what VS Code delivers today.
What you want is for basic text editing to run locally (to minimize latency) and heavy duty services (like language services or search) to run on the remote server where accessing a file only requires a file system call instead of a network call. Then, after gathering the required information it can send that over some kind of pipe to your text editor.
This is the workflow that VSCode has set up and it's very good. In many ways, even if you're used to vim, VSCode's setup is preferable to vim over ssh shell due to lower latency.
Yeah, it’s an efficient setup that doesn’t actually work because it’s lacking in features.
But I admit, I work on a weird product stitched from different languages, there's just no IDE that handles that particularly well as far as I know. If I was back to working on Python only I might switch back to PyCharm.
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...
But it is getting better, that's for sure. Looking forward to see upcoming iterations.
Early on I used Eclipse plugin for similar reasons - unified debugging across multiple platforms.
However your allegiance sounds interesting. Can you give some reasons why you like it so much?
In no particular order, here are all the things that I love about Pycharm and that Vscode doesn't really compete on at the moment:
1. Integration of IPython shell (if you install IPython in your project venv) with Pycharm is absolutely amazing. Copy-pasting multi-line code just works. It handles all the auto-indent stuff. You have keyboard shortcuts to directly send highlighted sections of code in the editor to the shell. You can even add a plugin (Python code cell) to make the editor work like Spyder/Matlab's cell mode
2. Excellent history browser of all commands entered in the IPython shell. This is extraordinarily handy as I end up doing all my code prototyping directly in the IPython REPL, fix all the edge cases and issues interactively, and then just grab the things that work and graduate them to a script/function/class. This reduces the overall time to code things up and I end up with far less bugs.
3. The code completion/intelligence is unbelievably good. Vscode's intellisense is really really bad in comparison when it comes to Python. With Vscode, the tab completion almost always feels nonsensical with the ordering of things making no sense, and a lot of times just plain wrong things being suggested in tab completion. By contrast, Pycharm's code completion is really smart, and extremely helpful, especially when filling in method signatures, or trying to tab-complete instance attributes/methods. It is smart enough to even parse type-hinting from docstrings and provide code completion accordingly, which vscode fails at.
4. Refactoring is a lot easier. Code inspection tools are pretty powerful
5. Related to the fantastic REPL experience in Pycharm, the debugging experience is hands-down the best Python debugging experience I have found. Also, the integrated variable viewer/explorer is really really nice and makes debugging that much easier/faster
6. PEP8 linting + auto style refactoring is really good in Pycharm. I've found vscode lacking considerably in that department. Pycharm ends up catching a lot of silly mistakes that vscode doesn't (example: forgetting to have your first param be `self` for an instance method).
7. Managing your project venvs and dependencies is also much easier and more robust in Pycharm. Pycharm will alert you the moment any file utilizes imports not installed in your venv and will also highlight missing dependencies in your requirements.txt / setup.py
I'm sure I'll think of more, but these are some of the top things that come to mind. It is a really fantastic product and what's crazy is that all of the above you get with the free community edition! I actually want to purchase the pro version but haven't found any need for it. I was interested in the remote-code development capabilities but unfortunately have been pretty underwhelmed by that aspect of Pycharm. Vscode seems to have a much better UX on that front imho.
PyCharm is (AFAIK) monolithic in what it brings to the table, whereas VSCode is more modular. As such, some of your points are true, but not an inherit fault of VSCode, but probably of some settings/underlying tools used. Maybe these can get you a better experience:
3. Agreed with VSCode being lackluster, but switching to MS Language Server [0] has helped this a great deal (while having other downsides, like being slower).
5. VSCode also has a variable viewer/browser and an interactive shell (which cannot be IPython as of today, however [1])
6. Disagree: I forgot what VSCode uses per default, but I switched to `black` for formatting, which works very well (` "python.formatting.provider": "black"` in settings.json). For linting, I switched to `mypy` (which also handles type hints, which is helpful), which can be set via `Python: Select Linter` (CTRL+SHIFT+P). `mypy` seems to be powerful. It definitely catches method 1st arguments not being `self`.
0: https://github.com/microsoft/python-language-server
1: https://stackoverflow.com/questions/47701629/vs-code-run-ipy...
6. Yup, it supports linting, but my point was that Pycharm has better overall support for linting/code-intelligence in that it is better at auto-fixing things or having shortcuts to do so, without having to resort to something as extreme as `black`. It handles multi-line strings, or just general formatting of multi-line stuff perfectly. If I hit enter after `long_var_name = `, it will automatically put in a back-slash so you can continue writing a multi-line expression. I edit in both vscode and pycharm and I usually will still find useful things that the Pycharm linter catches or code-formatting things that Vscode does not (and I have tried a dew different linters though perhaps I should give mypy a shot).
I raise all these as a big proponent of vscode. Nothing would make me happier than to switch to it for all my Python development work as I enjoy the UX a lot more over Pycharm in the code writing/editing side of things. But Pycharm is just superior in so many ways that improves my productivity that I have not been able to make the swap despite several attempts.
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.
But it's not pycharm; the debugger is very much lacking, often failing to resolve or step through.
But this is likely because Rust is not a primary target for the IDE.. I haven't tried any complex C++ in it yet.
It is very slow over sshfs for instance, whereas other editors work very well (sublime, vscode..). Also, vs code has a very good remote development plugin.
That said, it isn’t rocket surgery. ETL, web services, and FS/image tools lately.
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.
Log files have the benefit of being able to adjust the signal-to-noise afterwards, I guess that is why it is highlighted.
The book: https://www.goodreads.com/book/show/2092682.Programmers_at_W...
I have a newer edition, but I'm not at home now.
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
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.
From an efficiency standpoint, it would be hard to argue that print based debugging is faster. You can do everything you want via print debugging using a good debugger like in Pycharm or even ipdb, and without having to edit any lines of code (at least with the former). Meanwhile, the converse is not true... you are limited to a lot less with print-based debugging.
Furthermore, having tools like a variable viewer, or your editor window automatically showing variable values while debugging (as is the case with Pycharm) makes it a lot easier to reason about code as you debug and I am always much faster at working through issues when I go that route than if I go with print statements or even pdb without all the extra convenience I get from something like the Pycharm debugger.
And finally, it drives me up the wall to see sloppy code from some colleagues with tons of commented out lines like:
`# import pdb; pdb.set_trace()`
littered all over the place. It's both sloppy, and also really annoying when there are random changes in your git-history that are only because these lines keep popping in and out as they try to debug things.
Taking a snapshot of program state using log is isomorphic to freezing the program at that same state. The difference is that with the debugger you have the option to step into the next state or increase your resolution and look at state within a lower level module/function. With the debugger you have access to ALL state at the point where you froze it, not just statements you happened to log.
With logs, the way you debug is you log some state, reset the program with more logs and iterate until you find an issue. With a debugger you freeze the program examine all the state .... advance the program however far you want.... then the issue is found (unless you advanced the state too far ... but with logging the state ALWAYS advances too far until the end of execution, so with logging you always need to reset).
Logically, logging is just debugging with less features so people who prefer logging just in general don't want to use the extra features. Additionally logging has the added downside of constantly polluting your pristine code with your log annotations which you have to remove later (can introduce more bugs). While debugging with console PDB has the same effect, a GUI largely alleviates this problem.
The only argument for logging/printing is that you can use logging to debug an application in production.
I will add that I usually add various levels of debug log annotations even before I run into a bug so that I know what my program is doing.
Also, when I'm on an embedded platform that can't run a debugger or writing an exploit for a security vulnerability, being good at logging is nice.
There are also quite a few bugs where you need some kind of debugger in order to track down the bug. I am thinking crash dumps (using WinDbg for example) as well as memory corruption in C/C++. Being able to set a breakpoint when a certain address in memory changes has basically reduced most memory corruption bugs from a week-long nightmare to more of an inconvenience for me (mind you, it's still my least favourite type of bug to investigate).
Do you have a good tutorial on how this all ties together? It sounds like heaven but it's not how I use PyCharm because I don't know any better.
1. Open up the Python interpreter (highly recommend installing iPython in your project venv so you can use it as the default interpreter in Pycharm)
2. Setup toy data to prototype the thing you are trying to do (or just load in some data or a pickled file, etc.)
3. Start prototyping the functionality of your code one step at a time. If things need to be in a loop in your main script: eg: `for thing in things:` , I just set `thing = things[0]` in the REPL and then continue prototyping the logic of what goes in the inner loop.
4. Use the variable viewer, printing variables in the REPL, etc to make sure things are doing what you want
5. As sequences of statements are verified as doing what you want, you just "graduate" them to your script so you in effect know that they are somewhat tested and do what you wanted
6. Get to a point where you get the right result you were looking for
7. Now set `thing = things[4]` or some other edge-case and just run it a few times to make sure you still get the right result.
8. You're good to go. Wrap up the code in whatever function or class and you are ready to give it a shot for real
This sounds like more work, but it is super easy to execute code in the interpreter that you have in your editor (select code in script window, ALT + Shift + E to execute in interpreter)
Now the thing people might say is - Well, it is hard to always setup stuff with toy data, and that's true. In that case, you just set a debugger at the point where you would be writing your new function/method, and when you pause there, launch the interactive python interpretter within the debugger and you can start prototyping code from scratch in exactly the same way above, but in the debugger, with actual data you care about.
I find that you eliminate all the dumb/idiotic bugs in code this way and the only ones that I need to actually debug at times are certain edge cases I did not account for at the time of prototyping.
I wish there was more to how to actually debug in Jupyter or Spyder, and I'm relatively new to both, and was hoping for some tips on that.
I'd like to add two packages I learned about recently that I like A LOT: pyrasite and PySnooper.
Use pyrasite to "attach" to an existing running Python process (i.e. you forgot to instrument the app, but it has a bug in it, how can you debug?) (1) Install pyrasite (2) Get the PID of the running process (3) Run `pyrasite <pid> dumpstackz0.py` where dumpstackz0.pycontains `import traceback; traceback.print_stack()` (4) The stacktrace will be printed in the stdout/stderr of the running application
Use PySnooper instead of print-debugging—just add a decorator to any python function to get detailed debug info like you normally would get from a full debugger: (A) code: https://github.com/cool-RR/PySnooper (B) pypi: https://pypi.org/project/PySnooper/ (C) talk: https://www.youtube.com/watch?v=XP5imOJc_TE (D) podcast: https://www.youtube.com/watch?v=VUZvgJJKor0
import IPython; IPython.embed()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
import pudb; pudb.set_trace() import pudb; pu.db
IPython pdb session.
PDB as mentioned is great, but IPDB is at a whole 'nother level. If I'm able to get an ipdb breakpoint set in a tricky part of python code, I'm set. Tab-completion, some saved history, normal debugger operations, it's a dream-come true. I often set breakpoints and code iteratively w/ a repl-like interface or explore unfamiliar functions and objects.
I published that here:
https://pypi.org/project/better_exchook/ https://github.com/albertz/py_better_exchook
I also often have a SIGUSR1 handler which will print the stacktrace of all threads. This is useful on long running processes, involving multi threading, where you might run into some strange hangs or deadlocks.
In addition to that, if you might get crashes (segfault or so), something like faulthandler is useful.
If you also want to see the C stack trace in addition in such cases, I load libSegFault.so, like here: https://github.com/rwth-i6/returnn/blob/5b8e34ec1fd725d0e20b...
Profiling is another topic. Something like Py-Spy (https://github.com/benfred/py-spy) can be very helpful.
I also found a remote background ZMQ IPython/Jupyter kernel to be useful sometimes. I published that here: https://github.com/albertz/background-zmq-ipython
import pdb; pdb.set_trace()
breakpoint() import ipdb; ipdb.set_trace()
Above a troublesome line of code, drop this line:
import pdb; pdb.set_trace()
I guess this is a good workaround!
- 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.
My favorite tiny unique feature is that it injects variable values as temp comments in the code as the program runs in debug mode. So you're seeing `foo = get_foo() # "bar"` as your code. Really helps to debug complex algorithms when you can see the values right there in the code.
My only problem is that debugger shell feels very clunky with ideaVim plugin, so if someone at JetBrains reading this that would be a very welcome improvement!
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 guide to the next iteration of the code's form.
Concerning reloading, I find `%autoreload` much more reliable than `importlib.reload`. The latter can't handle `from lib import foo` or if a dependency inside an imported package changed. `%autoreload` just does this all automagically.
For context, I’m often working in a Django shell.
I am not the best programmer ... but I have always felt like an imposter with how many times I googled the next expression.
[1] https://github.com/microsoft/debugpy [2] https://github.com/microsoft/ptvsd
So within loki (or any similar log tools) all logger.info(repr(object)) is a link straight to the admin. Worth the set up time.
I've been using the Wing IDE for several years. It sometimes chokes when I try to inspect larger numpy arrays as a whole, using the application-specific array visualization (but there are other ways). Otherwise I'm quite happy with it.
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()
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...
You don’t need a different UI for debugging — you can just write the breakpoint into the code. Conditional breakpoints can be done with Python logic!
Marvelous!
I'm the opposite - immediately run in the debugger to probe around how to use this or that API or verify that the code is really doing what I think. I also find that stepping through my code early on often gives me insight in how to implement something more efficiently.
There are qualitative differences in the code we're usually modifying though; in particular, he's often editing code where the control flow is hard to reason about (inheritance towers, pages of conditionals, etc) and is fairly slow to build and run.
In that environment I might even reach for a debugger myself -- e.g., even if you already isolated the bug to a particular portion of the code and just wanted to know which method was being dispatched you would need a ton of print statements, or at least a lot of back-and-forths editing the code and figuring out where you ended up (because of the high branch complexity which could send you far from where you started), and those restarts would be fairly slow in and of themselves. Contrast that with a debugger where you can quickly step forward and find out exactly where you end up.
IMO, print statements are easier/faster to use than debuggers, so I reach for those first unless there's some feature a debugger has that I think will make my life easier overall.
This looks like the same article: https://dev.to/martinheinz/ultimate-guide-to-python-debuggin...
In the article you linked it mentions “This article was originally posted on [url]”, which links to the same article this post links to.
from IPython import embed
embed()I feel we're going to have a lot of fun together.
https://github.com/MartinHeinz/blog-backend
The frontend is built on Vue.js.
We have a flask app and one hurdle I had to overcome was our docs all assumed you'd run the app via gunicorn, but VSCode had trouble triggering breakpoints so I had to figure out how to run the app via the flask module directly, which was a bit of work since our app isn't following most of the getting started with flask tutorials conventions.
For another project we use celery, VSCode can be used to debug celery tasks but it's also work to set up and in the end I found using the rdb.set_trace() debugging provided by celery was easier. An important lesson I learned while working on that project is that you need to be sure you're setting your breakpoints in the right version of your app: if you are using a setup.py install step the code you want to debug is probably somewhere in site-packages not wherever you installed it from.
For another project, we're using python 2.7 on Centos 6: VSCode debugging & remote tools don't easily support that setup so knowing pdb or doing log debugging are the best bets. Something important on log-based debugging this article doesn't mention: if you're developing a long-running app like a daemon or service of some kind: you should probably make your log config loading dynamic. The one provided in the article is nice if your script is one-off, but if you are running a service you may want to be able to dynamically adjust the logging to be more verbose when an issue occurs and then reset it when done debugging without having to start/stop the whole service. I inherited code that runs as a service and in order to change the log level I have to stop the service, change the config and restart. The start/stop is destructive: if you stop the service the action it was performing has to be redone from the beginning. These are tasks that can take 8-12 hours so restarts are painful. Debug logs can be huge so you can't just leave the service in debug log mode all the time unless you want to fill up the whole disk. Which brings up another point: rotating log files—if you're doing heavy logging you need to be sure you have set up rotation so that you don't eat through disk space indiscriminately.
In my ideal world every project I work on could have breakpoints trigger my editor's tools so I can inspect and alter code on the fly, but knowing there's more than one way to go about it and how to approach it when you don't have control is important.
- "you might want to just copy-paste it and use it" ... that's maybe what people end up doing, but it's a terrible idea.
- The following `__repr__` is out of alignment with the output printed below it:
class Circle:
def __init__(self, x, y, radius):
self.x = x
self.y = y
self.radius = radius
def __repr__(self):
return f"Rectangle({self.x}, {self.y}, {self.radius})"
def __repr__(self):
name = self.__class__.__name__
return f"{name}({self.x}, {self.y}, {self.radius})"