While debugging, if you don't want a section of code to be executed temporarily, replace the expression after an 'if' or 'while' with '0' and comment out the old expression, leaving it in place.
1 2 3 4 5 6 7 8 9 | Before:
if i < 1:
doSomething()
After:
if 0: # i< 1
doSomething()
|
Not Python-specific. This is as much true for other languages like C or Perl... as it is for Python.
Dinu Gherman
Not very flexible. THis approach is not very flexible imo. If you were to have a whole bunch of such statements all over the code, then you keep changing back and forth between the debug and non-debug modes of operation. Easy for error prone and too much manual work. I would usually prefer to have a 'debug' variable defined some where in there and change the value to "0" or "1" and use that to control the program flow. That is how I usually do my debug. Love to hear from others. Srinivas B.
Play it safe. I would recommend against ever writing this:
in favor of this construct:
because it's quite dangerous to leave the incorrect code there... you might forget to put it back when you finish testing.
I'm not sure I would recommend the entire approach... if your editor provides any support you can write this:
with only a couple of keystrokes. This has the advantage that the ## on the left-hand-edge of the screen really shows up, and it's clear that you're really only testing.
-- Michael Chermside Michael Chermside
Not very flexible, part II. I'd echo what Srinivas said. Rather than changing code, using an "if debug:" approach makes much more sense. This is particularly true if you're debugging a large application, where you want the ability to turn on and off debugging code in different objects/modules w/o having to worry about side-effects.
Another method that might be worth exploring is an object-oriented logging approach. Most of the time, I use debugging sections to print info. In that case, using a "log" object makes more sense. In other words, rather than using
if debug: print counter
use
log.out(counter)
This way, not only is the code shorter, but it also allows you to change formatting of your debugging output depending on what you're doing. If you have an object that you use both for command-line apps and web apps, you can switch between the two by simply changing which version of log you use (e.g., one class of log, weblog, might replace every "\n" with a "<br>\n" so you can more clearly read the output). Anders Schneiderman
I am just illustrating a combination of Srinivas and Anders, since it is exactly what I use for any platform that I am developing on. Markdown is a good option for logging debug data as well. Here is essentially what I do.
I usually use multiple commandline arguments for different modes since it means I do not have to keep on toggling the DEBUG value in the source code. I also have created an entire logger module with a log class that uses different methods like:
It has worked pretty well thus far.
Wow, I feel stupid. Did not see the '10 years' in 10 year 11 months ago.