7 ms·

Why don't people just use a debugger? It boggles my mind that people live with print style debugging. Depending on the project, it can be such a timer waster an

Why don't people just use a debugger? It boggles my mind that people live with print style debugging. Depending on the project, it can be such a timer waster and just plainly worse in all aspects. Especially in Pycharm for me, it is incredibly easy. Even when running over ssh in remote computers I can use my debugger.

extrememacaroni 6y ago
uncle bob told me you don't wanna be good at using a debugger print("here") till the day i die!!!
CodeGlitch 6y ago
I find you need both. Print gives you a nice high level view of your code, whilst stepping let's you see what's happening. I would say I get more use out of printing these days.
chpmrc 6y ago
What do you use for remote debugging? And do you run all production instances with a debugging server attached? What's the overhead?
- mikkelam 6y ago
  I use Pycharm's native ssh interpreter toolhttps://www.jetbrains.com/help/pycharm/configuring-remote-interpreters-via-ssh.html https://www.jetbrains.com/help/pycharm/configuring-remote-in... It automatically syncs your local project with the remote machine and runs seamlessly. They have a similar offering for docker, but I have yet to try it when running over ssh.
globular-toast 6y ago
For me it's just lack of practice. This is rare enough for me that I would have to look up how to use the debugger each time. I never forget how to type print.
dataflow 6y ago
They're not perfect substitutes for each other. And not every python script that you need to quickly debug is worth firing up a while IDE for. Especially if your IDE requires creating a project and such. I say this as someone who very much loves Visual Studio.
pjc50 6y ago
It produces an ordered transcript of the whole run that you can visually scan quickly for the unexpected, and then paste bits of into your short-term notes file. It's easier to go back in time with print debugging: just scroll up. It also works in situations where debugging is infeasible or would slow down execution too much.
mckirk 6y ago
It's strange, when developing C# and the like I'd go crazy without a debugger... and yet, in Python I've hardly ever used one. That might be because it's hard to develop C# without already being in an environment that puts an emphasis on easy debugging (Visual Studio), whereas I'm developing Python in whatever text editor I happen to be using at the moment and never really bothered to try out anything other than the IDLE debugger -- which really isn't that great to use. Might be worth it to set up a better environment, then. Somehow I don't feel like print debugging is all that inferior though; in a sense it might actually make your debugging more efficient by forcing you to formulate concrete 'questions' about your code before even diving into the execution.
- roel_v 6y ago
  Writing Python (and most other languages) with a proper IDE with integrated debugger and all is like eating right and exercising: it's much better when you do it, you feel better while doing it, each time you start again you think "why did I ever give this up?", and yet it takes conscious effort to keep it up, circumstances just make it so tempting to fall off the train. 'Oh just checking the value of that constant, I'll just use Vim.'. 'It's just one trace line, I'll just use print.'. And before you know it you're back in the stone ages, and the circle repeats.
  - mikkelam 6y ago
    I really agree with this. I would love to be in a clean self-built environment in vim or sublime or the likes, but IDE's just work and boost productivity.
- fshbbdssbbgdd 6y ago
  For me the debugger really shines when I need to trace the behavior of some library. It’s worth the effort to instrument the codebase I’m working on with good logging, but doing that to every library I call would be insane.
enriquto 6y ago
> Why don't people just use a debugger? I only speak for myself, but I find that time spent inside a debugger is "lost", and bound to be re-spent again and again if you ever find new problems with the same code. I pretty much prefer to add assertions, logging and comments to my program, that will stay there and make further re-reads easier and more useful. As a matter of principle, I never use a debugger (except for assembly code, but that's rare nowadays).
- svantana 6y ago
  Asserts are great, but when they fail, you still need to figure out why it happened. Nice environments allow you to debug the state at the point of assertion, python certainly doesn't make that convenient.
- mixmastamyk 6y ago
  Agreed, and tests too.
- silon42 6y ago
  +1 Agreed. Unless you can immediately see the problem from back-trace and local variables, stepping through with the debugger is often a waste of time compared to adding some logging.
- haram_masala 6y ago
  Then you are either using a bad debugger, or you're not using one properly. A good, fully-featured debugger allows you to store sessions and configurations for various efforts and problems you're trying to diagnose, along with your notes and links to relevant issues.
  - enriquto 6y ago
    > Then you are either using a bad debugger, or you're not using one properly. You are certainly right, as I barely ever use a debugger and it is always an annoying experience. Can you suggest such good debuggers for C, Julia and Python? Sounds like these "sessions and configurations" are important, and thus they should be formally part of the program, committed to its public repository for all to see and use. I call these things "tests" and write them using the same language as the rest of the program, and run them frequently to be sure that they don't get out of sync with the program itself.
svantana 6y ago
Right?? I find it really sad that python being the go-to "beginner/mess-around" language has such poor debugging in most environments. I've tried VSCode, Atom, Juno, Spyder, Jupyter(lab) and Thonny. All of them were either broken, buggy or cumbersome to step-debug in while also using the REPL. I will give PyCharm a go though. The worst part is, I think a lot of devs resort to print-debugging which in turn leads to writing sloppy code - e.g. avoiding function calls to be able to access state, etc.
Stratoscope 6y ago
There is a place for both. Sometimes I really do want to see a sequence of events, or it may not be possible to run a debugger. I work on an automated voice agent for restaurant drive-throughs, specifically the code that connects the voice agent to the existing point of sale system. When something goes wrong in a store, having a log of the API interactions between the voice agent and the POS is essential for troubleshooting. Recently I updated the logging with a code generator option. I can place an order by voice on my local test setup, and it writes out a Python script that replays the same API calls, ready to run in a standalone API tester. This is super handy for testing. But none of this is a substitute for a good debugger. For me it is a powerful thing to be able to stop the code at a breakpoint and see the actual values of all the variables at that point in time. And it's not just for debugging. I jumped into this project after it had already been developed for a couple of years, and needless to say there is a lot that I did not understand about the code. Of course I can read the code and use Ctrl+Click in PyCharm to see the definition of a function. But to really understand it, there is nothing like setting a breakpoint and looking at live data.
Chris2048 6y ago
For what, exactly? Just saying "I can use my debugger" doesn't really help. Debuggers give you a lot of information at a particular point (stack frame) in execution time, whereby print-ing can give you a filtered view of what happen(ed) during a full run. When I can mark breakpoints and store the stack at that time (for each pass through that bp) in a inspectable gui tree (a list for linear execution path, a tree for threads etc) then I won't need print statements any more.
Hnrobert42 6y ago
Debuggers are great. But to unboggle your mind, here’s why I don’t use a Python debugger. I don’t write enough Python to justify the time to learn the debugger. I write just enough to help my staff/teammate fix their problem or debug some tool I’m using and move on. I’ve been doing this long enough to lose interest in digging deeply into each language. I learned gdb for C. After that I learned jdb and Eclipse for Java. There was probably something I used for the few years I wrote PERl later PHP. After a while I stopped getting excited about deeply learning new languages and their tools. Debuggers and IDEs are yet another dependency. Frequently I use systems I don’t control, like client systems. They have really stringent rules about what can be installed. The lowest common denominator is vim and print. Certainly there are lots of reasons to learn debuggers. But there are also lots of valid reasons to learn a tool like this which is easy to learn, useful in across many languages, and gets the job done in many situations.
- black3r 6y ago
  I just use IntelliJ IDEs for all programming languages I write in and the debugger experience is the same everywhere.
zestyping 6y ago
It depends on the situation. In general, debuggers give you much more contextual information, but using a debugger is extremely slow. To see what's going on, you have to step through your program, one line at a time, until the interesting thing happens. That can take ages. If you want to see how a specific function is behaving and it's called 100 times, it's a lot easier to look at a printed log of the 100 calls and scan or search it for interesting behaviour than to pause the program in a debugger and step through it over and over, hoping to catch the interesting moment.
- mixmastamyk 6y ago
  Yes, and sometimes I hit the wrong key and have to start again.
- klibertp 6y ago
  > you have to step through your program, one line at a time You can set more than one breakpoint at a time. Hitting 'c' will get you to the next breakpoint, no matter where it is. > and step through it over and over No, you don't (shouldn't) do that. You write a conditional breakpoint which activates when something interesting happens.
  - gwenzek 6y ago
    OTOH if you're able to write `if bug_will_happen_on_next_line(): breakpoint()` you're pretty much done debugging.
    - klibertp 6y ago
      No, when starting debugging you most often know the results of a bug. You can break conditionally on when the results appear, then work your way up the stack or jump to the beginning of a block to re-examine it. Or you can rerun the program, this time with a breakpoint set based on the inspection of the environment when the bug happened. In pdb not only can you set breakpoints with conditions[1], you can also assign commands to be executed when the breakpoint is reached[2]. You can also use `display` command to - effectively - insert temporary `print`s in any stack frame[3]. Coupled with `up`, `down`, and `jump` commands, and the ability to evaluate any code in the scope of a break, it really gives you a lot of options on how to find the problem. Though, logging is still a good thing. When I see a commented out `print` in code review, I usually suggest to replace it with a DEBUG level logger call. Extensive logging does help to trace the execution, it can be disabled when not needed, and can improve the readability of the code. Although raw print is an antipattern (can't easily enable some and disable other, need to clean up after debugging, doesn't display the stack trace, etc.), logging is a valid technique which complements the usage of a debugger nicely. [1] https://docs.python.org/3/library/pdb.html#pdbcommand-break https://docs.python.org/3/library/pdb.html#pdbcommand-break [2] https://docs.python.org/3/library/pdb.html#pdbcommand-commands https://docs.python.org/3/library/pdb.html#pdbcommand-comman... [3] https://docs.python.org/3/library/pdb.html#pdbcommand-display https://docs.python.org/3/library/pdb.html#pdbcommand-displa...
reportgunner 6y ago
print is built in and runs everywhere my code runs. It never breaks and i never have to remember to install it. I never have to configure it or update it.

extrememacaroni 6y ago

uncle bob told me you don't wanna be good at using a debugger print("here") till the day i die!!!

CodeGlitch 6y ago

I find you need both. Print gives you a nice high level view of your code, whilst stepping let's you see what's happening. I would say I get more use out of printing these days.

chpmrc 6y ago

What do you use for remote debugging? And do you run all production instances with a debugging server attached? What's the overhead?

mikkelam 6y ago
I use Pycharm's native ssh interpreter toolhttps://www.jetbrains.com/help/pycharm/configuring-remote-interpreters-via-ssh.html https://www.jetbrains.com/help/pycharm/configuring-remote-in... It automatically syncs your local project with the remote machine and runs seamlessly. They have a similar offering for docker, but I have yet to try it when running over ssh.

globular-toast 6y ago

For me it's just lack of practice. This is rare enough for me that I would have to look up how to use the debugger each time. I never forget how to type print.

dataflow 6y ago

They're not perfect substitutes for each other. And not every python script that you need to quickly debug is worth firing up a while IDE for. Especially if your IDE requires creating a project and such. I say this as someone who very much loves Visual Studio.

pjc50 6y ago

It produces an ordered transcript of the whole run that you can visually scan quickly for the unexpected, and then paste bits of into your short-term notes file. It's easier to go back in time with print debugging: just scroll up. It also works in situations where debugging is infeasible or would slow down execution too much.

mckirk 6y ago

It's strange, when developing C# and the like I'd go crazy without a debugger... and yet, in Python I've hardly ever used one. That might be because it's hard to develop C# without already being in an environment that puts an emphasis on easy debugging (Visual Studio), whereas I'm developing Python in whatever text editor I happen to be using at the moment and never really bothered to try out anything other than the IDLE debugger -- which really isn't that great to use. Might be worth it to set up a better environment, then. Somehow I don't feel like print debugging is all that inferior though; in a sense it might actually make your debugging more efficient by forcing you to formulate concrete 'questions' about your code before even diving into the execution.

roel_v 6y ago
Writing Python (and most other languages) with a proper IDE with integrated debugger and all is like eating right and exercising: it's much better when you do it, you feel better while doing it, each time you start again you think "why did I ever give this up?", and yet it takes conscious effort to keep it up, circumstances just make it so tempting to fall off the train. 'Oh just checking the value of that constant, I'll just use Vim.'. 'It's just one trace line, I'll just use print.'. And before you know it you're back in the stone ages, and the circle repeats.
- mikkelam 6y ago
  I really agree with this. I would love to be in a clean self-built environment in vim or sublime or the likes, but IDE's just work and boost productivity.
fshbbdssbbgdd 6y ago
For me the debugger really shines when I need to trace the behavior of some library. It’s worth the effort to instrument the codebase I’m working on with good logging, but doing that to every library I call would be insane.

enriquto 6y ago

> Why don't people just use a debugger? I only speak for myself, but I find that time spent inside a debugger is "lost", and bound to be re-spent again and again if you ever find new problems with the same code. I pretty much prefer to add assertions, logging and comments to my program, that will stay there and make further re-reads easier and more useful. As a matter of principle, I never use a debugger (except for assembly code, but that's rare nowadays).

svantana 6y ago
Asserts are great, but when they fail, you still need to figure out why it happened. Nice environments allow you to debug the state at the point of assertion, python certainly doesn't make that convenient.
mixmastamyk 6y ago
Agreed, and tests too.
silon42 6y ago
+1 Agreed. Unless you can immediately see the problem from back-trace and local variables, stepping through with the debugger is often a waste of time compared to adding some logging.
haram_masala 6y ago
Then you are either using a bad debugger, or you're not using one properly. A good, fully-featured debugger allows you to store sessions and configurations for various efforts and problems you're trying to diagnose, along with your notes and links to relevant issues.
- enriquto 6y ago
  > Then you are either using a bad debugger, or you're not using one properly. You are certainly right, as I barely ever use a debugger and it is always an annoying experience. Can you suggest such good debuggers for C, Julia and Python? Sounds like these "sessions and configurations" are important, and thus they should be formally part of the program, committed to its public repository for all to see and use. I call these things "tests" and write them using the same language as the rest of the program, and run them frequently to be sure that they don't get out of sync with the program itself.

svantana 6y ago

Right?? I find it really sad that python being the go-to "beginner/mess-around" language has such poor debugging in most environments. I've tried VSCode, Atom, Juno, Spyder, Jupyter(lab) and Thonny. All of them were either broken, buggy or cumbersome to step-debug in while also using the REPL. I will give PyCharm a go though. The worst part is, I think a lot of devs resort to print-debugging which in turn leads to writing sloppy code - e.g. avoiding function calls to be able to access state, etc.

Stratoscope 6y ago

There is a place for both. Sometimes I really do want to see a sequence of events, or it may not be possible to run a debugger. I work on an automated voice agent for restaurant drive-throughs, specifically the code that connects the voice agent to the existing point of sale system. When something goes wrong in a store, having a log of the API interactions between the voice agent and the POS is essential for troubleshooting. Recently I updated the logging with a code generator option. I can place an order by voice on my local test setup, and it writes out a Python script that replays the same API calls, ready to run in a standalone API tester. This is super handy for testing. But none of this is a substitute for a good debugger. For me it is a powerful thing to be able to stop the code at a breakpoint and see the actual values of all the variables at that point in time. And it's not just for debugging. I jumped into this project after it had already been developed for a couple of years, and needless to say there is a lot that I did not understand about the code. Of course I can read the code and use Ctrl+Click in PyCharm to see the definition of a function. But to really understand it, there is nothing like setting a breakpoint and looking at live data.

Chris2048 6y ago

For what, exactly? Just saying "I can use my debugger" doesn't really help. Debuggers give you a lot of information at a particular point (stack frame) in execution time, whereby print-ing can give you a filtered view of what happen(ed) during a full run. When I can mark breakpoints and store the stack at that time (for each pass through that bp) in a inspectable gui tree (a list for linear execution path, a tree for threads etc) then I won't need print statements any more.

Hnrobert42 6y ago

Debuggers are great. But to unboggle your mind, here’s why I don’t use a Python debugger. I don’t write enough Python to justify the time to learn the debugger. I write just enough to help my staff/teammate fix their problem or debug some tool I’m using and move on. I’ve been doing this long enough to lose interest in digging deeply into each language. I learned gdb for C. After that I learned jdb and Eclipse for Java. There was probably something I used for the few years I wrote PERl later PHP. After a while I stopped getting excited about deeply learning new languages and their tools. Debuggers and IDEs are yet another dependency. Frequently I use systems I don’t control, like client systems. They have really stringent rules about what can be installed. The lowest common denominator is vim and print. Certainly there are lots of reasons to learn debuggers. But there are also lots of valid reasons to learn a tool like this which is easy to learn, useful in across many languages, and gets the job done in many situations.

black3r 6y ago
I just use IntelliJ IDEs for all programming languages I write in and the debugger experience is the same everywhere.

zestyping 6y ago

It depends on the situation. In general, debuggers give you much more contextual information, but using a debugger is extremely slow. To see what's going on, you have to step through your program, one line at a time, until the interesting thing happens. That can take ages. If you want to see how a specific function is behaving and it's called 100 times, it's a lot easier to look at a printed log of the 100 calls and scan or search it for interesting behaviour than to pause the program in a debugger and step through it over and over, hoping to catch the interesting moment.

mixmastamyk 6y ago
Yes, and sometimes I hit the wrong key and have to start again.
klibertp 6y ago
> you have to step through your program, one line at a time You can set more than one breakpoint at a time. Hitting 'c' will get you to the next breakpoint, no matter where it is. > and step through it over and over No, you don't (shouldn't) do that. You write a conditional breakpoint which activates when something interesting happens.
- gwenzek 6y ago
  OTOH if you're able to write `if bug_will_happen_on_next_line(): breakpoint()` you're pretty much done debugging.
  - klibertp 6y ago
    No, when starting debugging you most often know the results of a bug. You can break conditionally on when the results appear, then work your way up the stack or jump to the beginning of a block to re-examine it. Or you can rerun the program, this time with a breakpoint set based on the inspection of the environment when the bug happened. In pdb not only can you set breakpoints with conditions[1], you can also assign commands to be executed when the breakpoint is reached[2]. You can also use `display` command to - effectively - insert temporary `print`s in any stack frame[3]. Coupled with `up`, `down`, and `jump` commands, and the ability to evaluate any code in the scope of a break, it really gives you a lot of options on how to find the problem. Though, logging is still a good thing. When I see a commented out `print` in code review, I usually suggest to replace it with a DEBUG level logger call. Extensive logging does help to trace the execution, it can be disabled when not needed, and can improve the readability of the code. Although raw print is an antipattern (can't easily enable some and disable other, need to clean up after debugging, doesn't display the stack trace, etc.), logging is a valid technique which complements the usage of a debugger nicely. [1] https://docs.python.org/3/library/pdb.html#pdbcommand-break https://docs.python.org/3/library/pdb.html#pdbcommand-break [2] https://docs.python.org/3/library/pdb.html#pdbcommand-commands https://docs.python.org/3/library/pdb.html#pdbcommand-comman... [3] https://docs.python.org/3/library/pdb.html#pdbcommand-display https://docs.python.org/3/library/pdb.html#pdbcommand-displa...

reportgunner 6y ago

print is built in and runs everywhere my code runs. It never breaks and i never have to remember to install it. I never have to configure it or update it.