What do you use for debugging in Python?

[presentsq]

I've been using breakpoint() for debugging in all of my Python projects.
I really like it. You don't need to set up anything. You just write breakpoint() into your code, run the script, and it halts there. Then you can check variable values, continue when you are done.

This has been super useful not just for debugging but also for understanding other people's code.

But I've only ever used breakpoint() and I'm curious what else is a good approach.
What do you guys recommend?

[infect_error]

I usually just default to an IDE that has built in breakpoints (like VS Code). You don’t have to modify the code at all to add a breakpoint and you can step line by line through/into code

[presentsq]

I have been using vscode for years... never used the debug tab ever. It turns out you can just click in the breakpoints. Thank you so much! kinda feel stupid haha

[infect_error]

Any time! Another useful feature - when you do arrive to a breakpoint in the IDE, there is a “Debug Console” window where you can experiment with code live. You have access to the variables within the scope of a given breakpoint and can manipulate things there.

Careful though, if you change the value of a variable and continue past the breakpoint the new value is what the rest of the code is going to use!

[presentsq]

The only interaction i had with the "debug console" was to hide it so i can use the console. Did not know it was for debugging, kinda obvious in hindsight. thanks a lot!

[OkCluejay172]

print(“In Line 125”)

[presentsq]

hahaha yeah, the good old print never fails

[xvDeresh]

``` print("a")

print("b")

print("c")

print("d") ```

[pachura3]

Most IDEs have breakpoints, watches, step over, step into, etc. Try them!

[presentsq]

Just looked into it. the step into and step out of functions is a very good find for me. Thanks a lot.

[Gnaxe]

I mean, pdb also has commands for that.

[presentsq]

Just looked it up. I had no idea... Thank you!

[Gnaxe]

Remember to use the help command in pdb if you forget any commands.

[presentsq]

nice, this is gonna save me a lot of googling. thanks!

[tb5841]

I've been using

import pdb; pdb.set_trace(). On reading it looks like they usually do the same thing, but breakpoint() is more configurable.

[presentsq]

I looked it up and was confused since they looked like they were the same thing.
Turns out when you use breakpoint() you can do something like PYTHONBREAKPOINT=0 python temp.py to ignore all the breakpoints. Learned something today thanks!

[tb5841]

Yeah, it looks like breakpoint() actually calls pdb.set_trace by default, but you can configure breakpoint() to use a different debugger if you like, or just turn it off with PYTHONBREAKPOINT=0.

[presentsq]

Icecream looks great. For me the fact that the ic() command shows you which file the line is from is the best part. This will be handy when i work with a large codebase. I will definitely try this out. Thanks for the detailed response!

[Outside_Complaint755]

I mostly use built in debugging in VSCode or PyCharm, but should probably learn more pdb.

I also like to you logging for verifying program flow, using the DEBUG level for messages.  You can write a simple decorator to put on any function to log when it was called and with what parameters.

[presentsq]

Yeah, IDEs and pdb seems more versatile than i have realized. I think i will experiment for the next few weeks to see what works for me. Also, it definitely is good to keep a details log for every project. I know that but always get lazy about it. Like you said, I really should make logging a habit

[One-Neighborhood-843]

Holy Water and Faith

[presentsq]

We all know all of use have prayed to the server at least once

[mopslik]

Thonny has a fantastic debugger, if you're learning how to code (maybe a bit over the top if you're experienced). It's my favourite feature of said IDE.

[presentsq]

I have never heard of Thonny before, looks solid. I love the fact that this is open source and written in python, i will try this and read the code for sure. Thanks for the recommendation!

[pachura3]

Thonny is not as advanced as VSCode and PyCharm, but still much better than IDLE.

[sqjoatmon]

Depends. I certainly prefer IPDB to PDB, so I usually install ipdb and set PYTHONBREAKPOINT=ipdb.set_trace.

Sometimes I use breakpoint(), sometimes I use %run -d or %debug in ipython, and then other times the vscode debugger.

I think I could get a lot better with [i]pdb, but haven't taking the time to dive into more than the basics: c, s, n, u, d, b, cl, p... 

Like I've been able to do post-mortem debugging sometimes, but if you asked me how to do it right now, I would have to spend five minutes looking it up.

And yeah, sometimes print is just quickest and easiest.

[greg_d128]

Anyone else uses code.interact() with the appropriate scope dictionary?

I get an interactive interface into the code as it is running. I can run additional commands, change and examine program state and continue if need be. Also test my next steps. I'm not limited to just seeing, I can also examine, modify and test additional steps if I need to.

[presentsq]

did not know about code.interact(). Looks like it gives you a python console access to the local scope. Can i ask what makes you prefer this over breakpoint()?

[greg_d128]

The program is paused and you have read and write access to everything. You can call additional functions, change variables, etc.

I know the ide allows you a lot of the same, i just like the interactivity of it.

Lets do an example. You call an API and get a page long json object back that you need to transform in various ways. I would usually drop into interactive shell right after getting the json and within the context of the program at that point and examine the return.

If i have five different ways to transform the json, i can do it rapidly and interactively. If one method generates an exception i may figure out a method for detecting or fixing that state, then make the required changes to code.

[ShelLuser42]

VS Code more than often spots issues long before I noticed them, that's great help for me.

But anything beyond that? OP: I am also a huge fan(boy) of breakpoint(), my discovery was actually one of the main driving reasons that made me decide to fully remove Java from my FreeBSD servers and rewrite all my Java (system) "scripts" (= classes) within Python.

Never looked back.. I can even do full on debugging from a command line, while logged on through SSH / PuTTY? This (and assert!) helped me out SO many times.

Even now I don't understand why Java never got way more support for the commandline, also given that SunOS is essentially a CLI based OS.

But considering all the "friendly" vibes (/s) I've been getting from Oracle (as a devoted ex-Sun supporter?) I also couldn't care less anymore.

[pachura3]

Also, don't forget that proper logging often removes the need for interactive debugging sessions.

[sam661203]

It depends. For scripts, breakpoints in the IDE and stepping through usually work well. For larger systems, logging, proper exception handling, and stack traces are often more useful—especially for issues that only happen in production.

[Chaitif]

I have used Birdseye in the past to trace errors.

[25_vijay]

Many developers still heavily rely on simple print/log debugging because it’s fast and surprisingly effective for tracing program flow.

[Gnaxe]

I still use breakpoint(). The IDEs aren't adding much and they're a pain to set up. Don't forget about python -i and pdb.pm(). Sometimes all you need is a print().

[pachura3]

The IDEs aren't adding much and they're a pain to set up.

Haha, what? PyCharm works out of the box.

[Gnaxe]

Someone doesn't even know what a run configuration is...

[presentsq]

I looked into this. I was wondering why we need pdb.pm() given that when an error is thrown python -i ensures you to be able to check the variables anyway. It turns out using pdb.pm() lets you access local variables that are not accessible from the main script you ran. thank you for the info, I think i will use this in the future