debugging code

[beliavsky]

If I have some debugging code in a Python program (mostly print
statements) and I want to turn it "off", two obvious methods are to
(1) comment out the code
(2) set a logical 'debug' variable at the beginning and use it to
conditionally run the debugging code.

Is there a better way? Some other languages have conditional
compilation. (I don't know if that is better or worse). What is the
"best" way to maintain "production" and "debugging" versions of a
Python program at the same time, preferably in the same file?

 

[Diez B. Roggisch]

If I have some debugging code in a Python program (mostly print
statements) and I want to turn it "off", two obvious methods are to
(1) comment out the code
(2) set a logical 'debug' variable at the beginning and use it to
conditionally run the debugging code.

Is there a better way? Some other languages have conditional
compilation. (I don't know if that is better or worse). What is the
"best" way to maintain "production" and "debugging" versions of a
Python program at the same time, preferably in the same file?

Since 2.3, python features a log4j-like logging api - look in the modules
doc for 'logging'. It uses different levels of logging that can be set so
that the output gets suppressed if the level is below the configured one.

A preprocessor variant doesn't exist.

 

[Larry Bates]

Since Python isn't "compiled", there is no such thing as
conditional compilation. I always have _debug and _trace
variables and use simple if _debug: and if _trace: statements
to test them (actually I allow debug to have levels that
show additional detail as I need it). I almost always read
these from the argument list on the processor call so I can
turn them on easily. I also read them from .INI file for
those programs that have one. Seems to work very well and
there is almost no overhead to them when turned off.

FYI,
Larry Bates
Syscon, Inc.

 

[Rick Ratzel]

Python defines __debug__ to True by default, and False when
optimizations are enabled...meaning you can enable/disable code without
having to define/undefine vars ahead of time and without having to
change it prior to deployment. This is how the "assert" statement
works. You can only set __debug__ through the use of -O or -OO.

For example, you can define a func like this:

def printDebugStmt( stmt ) :
if __debug__ : print stmt


....and use it like this:

$ python
$ python -O
....just remember to "ship" your app so it runs Python with -O or -OO.
BTW: you can use freeze.py with -O or -OO to get the same result for a
"frozen" app.

-Rick

 

[Paul Sweeney]

Python defines __debug__ to True by default, and False when
optimizations are enabled...meaning you can enable/disable code without
having to define/undefine vars ahead of time and without having to
change it prior to deployment. This is how the "assert" statement
works.

I agree with Rick on using __debug__ not your own variables, as suggested
elsewhere

You can only set __debug__ through the use of -O or -OO.

There is a typo here (but all the examples that followed were correct), You
can only set __debug__ *to False* through the use of -O or -OO.

 

[beliavsky]

Python defines __debug__ to True by default, and False when
optimizations are enabled...meaning you can enable/disable code without
having to define/undefine vars ahead of time and without having to
change it prior to deployment. This is how the "assert" statement
works. You can only set __debug__ through the use of -O or -OO.

<SNIP>

Thanks -- I will take your suggestion. Where are the Python command
line options like -O and -OO documented? Typing 'python -h' just gives
me

-O : optimize generated bytecode (a tad; also PYTHONOPTIMIZE=x)
-OO : remove doc-strings in addition to the -O optimizations

 

[Rick Ratzel]

<SNIP>

Thanks -- I will take your suggestion. Where are the Python command
line options like -O and -OO documented? Typing 'python -h' just gives
me

-O : optimize generated bytecode (a tad; also PYTHONOPTIMIZE=x)
-OO : remove doc-strings in addition to the -O optimizations

Thats strange. Here they are for Python 2.3.3 as built on my system
(should be the same for you):

[rlratzel@gt6 ~] python -h
usage: python [option] ... [-c cmd | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-c cmd : program passed in as string (terminates option list)
-d : debug output from parser (also PYTHONDEBUG=x)
-E : ignore environment variables (such as PYTHONPATH)
-h : print this help message and exit
-i : inspect interactively after running script, (also PYTHONINSPECT=x)
and force prompts, even if stdin does not appear to be a terminal
-O : optimize generated bytecode (a tad; also PYTHONOPTIMIZE=x)
-OO : remove doc-strings in addition to the -O optimizations
-Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew
-S : don't imply 'import site' on initialization
-t : issue warnings about inconsistent tab usage (-tt: issue errors)
-u : unbuffered binary stdout and stderr (also PYTHONUNBUFFERED=x)
see man page for details on internal buffering relating to '-u'
-v : verbose (trace import statements) (also PYTHONVERBOSE=x)
-V : print the Python version number and exit
-W arg : warning control (arg is action:message:category:module:lineno)
-x : skip first line of source, allowing use of non-Unix forms of #!cmd
file : program read from script file
- : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH : ':'-separated list of directories prefixed to the
default module search path. The result is sys.path.
PYTHONHOME : alternate <prefix> directory (or <prefix>:<exec_prefix>).
The default module search path uses <prefix>/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements (Windows).

 

[beliavsky]

Thats strange. Here they are for Python 2.3.3 as built on my system
(should be the same for you):

<SNIP>

I get the same output from 'python -h'. What I meant to say is that I
am looking for more detailed documentation of the Python interpreter
options. I looked briefly on python.org and did not find it.

 

[Thomas Heller]

<SNIP>

I get the same output from 'python -h'. What I meant to say is that I
am looking for more detailed documentation of the Python interpreter
options. I looked briefly on python.org and did not find it.

http://www.python.org/doc/current/ref/assert.html#l2h-460

Thomas