debugging code

Discussion in 'Python' started by beliavsky@aol.com, Apr 27, 2004.

  1. Guest

    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?
    , Apr 27, 2004
    #1
    1. Advertising

  2. wrote:

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

    --
    Regards,

    Diez B. Roggisch
    Diez B. Roggisch, Apr 27, 2004
    #2
    1. Advertising

  3. Larry Bates Guest

    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.

    <> wrote in message
    news:...
    > 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?
    Larry Bates, Apr 27, 2004
    #3
  4. Rick Ratzel Guest

    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
    >>> i=3
    >>> printDebugStmt( "Hello World...i = %s" % i )

    Hello World...i = 3
    >>>


    $ python -O
    >>> i=3
    >>> printDebugStmt( "Hello World...i = %s" % i )
    >>>


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


    wrote:
    > 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?
    Rick Ratzel, Apr 27, 2004
    #4
  5. Paul Sweeney Guest

    "Rick Ratzel" <> wrote in message
    news:408ee541$0$46510$...
    >
    > 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.
    Paul Sweeney, Apr 28, 2004
    #5
  6. Guest

    Rick Ratzel <> wrote in message news:<408ee541$0$46510$>...
    > 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
    , Apr 28, 2004
    #6
  7. Rick Ratzel Guest

    wrote:
    >
    > <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).
    Rick Ratzel, Apr 28, 2004
    #7
  8. Guest

    Rick Ratzel <> wrote in message news:<408fe602$0$3708$>...
    > wrote:
    > >
    > > <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):


    <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.
    , Apr 29, 2004
    #8
  9. writes:

    > Rick Ratzel <> wrote in message news:<408fe602$0$3708$>...
    >> wrote:
    >> >
    >> > <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):

    >
    > <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
    Thomas Heller, Apr 29, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eitan M
    Replies:
    1
    Views:
    856
    Alexey Smirnov
    Mar 30, 2006
  2. Johann Blake
    Replies:
    1
    Views:
    1,200
    Hermit Dave
    Jan 5, 2004
  3. moondaddy
    Replies:
    3
    Views:
    499
    [MSFT]
    Mar 3, 2004
  4. jacob navia

    Debugging C vs debugging C++

    jacob navia, Oct 26, 2006, in forum: C Programming
    Replies:
    11
    Views:
    591
    Ian Collins
    Oct 27, 2006
  5. AAaron123
    Replies:
    3
    Views:
    661
    AAaron123
    Jul 28, 2009
Loading...

Share This Page