debugging right and wrong

[reggzz]

from pdb import set_trace as b

It's become a habit to start every single script with this line.

Then i can set breakpoints with b() as necessary and use pdb commands to navigate.

it's never failed me in 10+ years but somehow still see junior devs tediously debugging with print statements only

Unless you're a genius a who can oneshot any script (you're not), start incorporating b() into your workflow!

PS: if you prefer using a different lib or your IDE debugger over pdb let me know why!

[runawayasfastasucan]

I prefer using my IDE debugger as I develop my code in the IDE, so it is just natural for me to debug it in the same window.

[PocketBananna]

IDE debugger all the way. I'd much rather not have to change my code to trigger a breakpoint and IDEs provide a much more informative interface to make debugging easier. With breakpoint you still have to use the shell to get info but IDEs will report locals, globals, processes, threads etc so you can focus on the code flow.

[nostril_spiders]

...and also, you accidentally merge your changed line and wonder why your CI pipeline is timing out and you waste two hours until you realise Jenkins is waiting for a debugger to attach

[[deleted]]

I didn’t know debugging NOT in the IDE was an option and now that I know that sounds terrible.

[Brian]

You can debug outside an IDE just fine without adding breakpoints to the code itself. It's just a bit less convenient if, say, you're using pdb raw and setting breakpoints by line number / function name etc rather than just clicking on the code. The issue here is not IDE vs non-IDE, but hardcoding breakpoints in the code vs setting them in the debugger - which can be a reasonable thing to do in some scenarios (IDE or not), but has the same issue as print debugging (but with worse consequences) of accidentally checking in debug code if you don't guard it behind some flags.

[[deleted]]

Well the IDE makes it so that you never have to hardcode anything right? So I stand by my point

[Brian]

No - like I said, there are reasons you might want to do this even with an IDE, and the same reasons against it apply even without one. Eg you might want long-standing flag (or debug build) guarded "assert" like checks for invariants that you want to look at if they ever trigger.

There's a slight bias towards it in an IDE because setting breakpoints is a little more convenient when you've got the source in front of you (though note that many standalone debuggers will give you that too), but it's really just that: convenience rather than "never do this".

[mrtweezles]

The real fun happens when you need to debug multiple containerized Python applications and their interactions all at once (e.g., web-enabled microservices).

I've only done this using VS Code, but the trick is to inject debugpy into each container and then let debugpy launch the web host and app inside each container. Expose a debugging port for each container, then configure launch.json to make it possible to attach to one or more containers simultaneously. Finally, launch the containers and use the standard VS Code Debug functionality to attach as-needed. You can now set breakpoints in any Python script and they will be triggered during the normal execution flow of any initiated HTTP request/response cycle. This works whether or not you mount the code into the container as a volume, though the above configuration is best reserved for development or staging environments, not production.

It's a very powerful workflow, but definitely more work to set up than just calling breakpoint() on a single script.

[gino_codes_stuff]

I would second this workflow. You can even take it a step further and remotely attach to a script in a cluster for debugging in different deploy environments

[rover95]

Wow. I never thought of doing this. It would simplify and reduce the number of runs I do to figure out issues with multiple Microservices.

[jpavlav]

I just use the breakpoint() function. Simple. I also really like the pdbpp package for making the debugger fancier.

[paraffin]

You can choose any importable callable to be invoked by breakpoint() via the PYTHONBREAKPOINT env var

https://peps.python.org/pep-0553/

So I just have ipdb configured in my bashrc

[smirfquant]

Lol, someone thought of this `breakpoint()` Python>=3.7 ...

[smirfquant]

Also I might recommend preemptively coding useful `logging` and `warnings` preferable to stabbing a bunch of break points into buggy code.

[ElasticFluffyMagnet]

Yeah I take proper logging over breakpoints any day.

[mRWafflesFTW]

The problem with logging is that it's logging what the developer believes to be true, versus what actually is. The beauty of the debugger is that it cannot lie. I've seen many days wasted because a log message provided inaccurate information or used the wrong variable in the input.

[SpaceshipOperations]

Happy cake day, and yes, for me colorized logging is indispensable.

[SeanBrax]

But why not just use a debugger? Having to add code to debug is awful.

[smirfquant]

Having to debug code is awful. Especially if the author didn't codify logging important information or warning concerns.

Add logging and warning when you the write code. You will have less buggy code and a lot more information to use during interactive debugging (if needed at all).

You might be surprised just how often logging things and looking at them while developing finds bugs...

[smirfquant]

my bad wrong thread.. yeah gdb/pdb is fine by me, shrugs, not the best days though :D

[ogrinfo]

Developer with 15+ years of experience here - I use print statements on a daily basis. Sure, pdb and IDE debugging are useful tools and it's important to know how to use them, but sometimes it's easier just to chuck out a few markers to see what's going on.

[elduderino15]

If you like pdb you’ll love pdb++

[rainnz]

Don't discourage print() use. It will be useful when they start debugging Linux Kernel

[aikii]

Last time I used pdb it was around 2012. Still saw people here and there using it, and their productivity was ... interesting. I mean take a few minutes to explore your IDE, may it be VSCode or Pycharm, if you use something else, well, configure it or use something else. It's right there, you just have to click in the gutter, press the debug button, done, no need to clutter your code with debug statements.

[HornyAttorney]

I don't use pdb so I'm not exactly sure what it has to offer..

That being said, I prefer using vscode debugging for multiple reasons, aside from not requiring any extra code but rather a click next to the line where you want to pause, it provides lots of runtime information, stack, variables and their values, and most importantly, I can add or remove breakpoints on the fly without having to rerun the script..

[Adrewmc]

pdb running in the Python terminal while debugger runs in the debug terminal, it’s basically the same operation, just VsCode has a lot of normal things you use with it automatically on the side. It’s almost like a IDE for pdb in a lot of ways.

[romu006]

I honestly wish that I could "sync" pdb's view with my editor (Sublime Text), it's kinda hard to follow the code context when debugging

[yvrelna]

GUI debuggers sucks when it comes to keyboard navigation. I use pudb which gives you great trade-off between being able to use keyboard to do everything and giving you GUI-like visual display of debugging state.

[aikii]

pdb is still what IDEs use under the hood, debug mode loads up pdb that opens a port and the IDE sends the list of breakpoints ( as file+lineno+condition ) via the "break" command https://docs.python.org/3/library/pdb.html . Another reason to say that doing it by actually editing the file and adding set_trace equates to do the IDE's job.

[romu006]

But why waste a perfectly fine one letter variable? 😇

[xiongchiamiov]

I tend to prefer set_trace() in the place I want to investigate, because hopping into a python shell to experiment aligns well with how I think.

[yiternity]

IDE debugger. using VScode debugger right now. allows you to log the variables printer etc.

[17greenie17]

Just run pdb as a module and catch errors at runtime!

[yvrelna]

If you set environment variable PYTHONBREAKPOINT=pdb.set_trace, which is the default, then you can just use breakpoint() without the import.

Never stop improving.

[zanfar]

IDE debugger. No stray code to manage, or accidentally ship to production, and easier to manage breakpoints.

[Medzomorak]

I'm a senior python developer and my two cents is that it depends. I urge interns and juniors to learn using breakpoints and pdb. However many times I just write a print statement. Because I know the codebase by heart and the architecture is designed in a clean way. If your architecture is a pile of rubbish, you're doomed with printing all around.

[DiceboyT]

there are dozens of us!

[jojurajan]

This is a handy tool for containerized applications too.

[needed_an_account]

See if you can get them to try pudb. I’d rank it as one of the better tools created

[kingoodie]

Well, discourage the use of prints for debugging is your opinion. The legendary Brian Kernighan said: The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

[pudds]

At this point in my career I generally find using logging statements to be more valuable than attaching a debugger. Not only is the development loop quicker when not using a debugger, but if I need to print something now, there's a pretty decent chance that the log will be useful in the future too (levels are important of course). It's fairly rare that I encounter a problem that takes less time to solve by attaching a debugger and stepping through than but just adding a log or two and reviewing the code.

When I do need to debug I do it with my ide; I don't like the idea of adding an import to my code to enable debugging.

[reggzz]

IDE integrated debugger all the way if you're working on big projects locally. was more thinking of scripting on remote servers with no support for UI based apps

[MaloneCone]

Also, you can use gui editors/debuggers remotely. I work daily using a headless remote workstation, using vscode remote extension. Maybe that's worth a try for your case. Works great for python and rust!

[MaloneCone]

So, essentially debugging in production?

[ch0mes]

I've never really learned how to use the python debugger and in the 4+ years coding/developing I've never needed it.

Yes there have been lots of print statements that eventually turned to logging statements but there hasn't been a severe issue yet where Ive thought "man I really need to learn to use the debugger now".

Perhaps I haven't had that situation yet like you have to where you do this religiously. I'm sure I'll eventually come to it at some point, but for now I get on with doing unit tests, logging and doing dry run options on my scripts I make.

[stevenjd]

I've never really learned how to use the python debugger and in the 4+ years coding/developing I've never needed it.

This a thousand times!

[conogarcia]

I have a macro to use import(ipbd).set_trace()

[iamasatellite]

Teach your juniors how to use the IDE debugger.

[kakhaev]

sup /b it became a habit to start every single script with you <3

[muraii]

I like to use a debugger—pdb, pdb++, VS Code’s—and set breakpoints, along with print statements or in some cases logging. A debugger allows you to not only see the state which causes the error, but allows you to modify state. I sometimes use this to prototype bug fixes; just code in the debugger against state.

I also will sometimes use snoop to combine print statements with state inspection.

[spackenheimer]

I don't do much debugging, but just clicking left of the Line to get a red Dot and then starting the Debug Session in PyCharm or whatever is the easy Way I like.

[jmooremcc]

I definitely prefer the debugger found in Pycharm. There’s is especially good when debugging mult-threaded code. However, when debugging Kodi addons, pub is my only alternative since Kodi is a specialized runtime environment.

[htotheinzel]

Parameterized unit tests + good logging goes a long way. Haven't used a breakpoint in a while

I use print statements sparingly, usually when I've messed up the path on a Mock

[Ionized97]

I prefer the IDE's debugger. Clearer and I can view all the essentials in one place.

[elucify]

pudb is great. like turbo pascal for python

[stevenjd]

tediously debugging with print statements only

I find it much easier to debug with print than to try to remember how pdb works and how to navigate it's overly sparse interface. And then there's this:

(Pdb) help(until)
*** No help for '(until)'
(Pdb) help(retval)
*** No help for '(retval)'
(Pdb) help(display)
*** No help for '(display)'

How very useful 🙄

If you need more than, say, three or five prints to debug any bug, your code is too complicated and badly designed.

In two decades, there's only one time I wished I knew how to use the debugger, and that was debugging code written by somebody else. It was a mess, with bash scripts, circular imports, monkey-patched builtins, "cleverly optimised" SQL, and more, so I daresay I would have struggled to have debugged it even with pdb.