3 ms·

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,

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...

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...