idiom for debug code? [1/1]

Ian Parker parker at
Sat Oct 2 21:24:19 CEST 2004

In message <6tadnfHqDdcg9cHcRVn-hQ at>, Dan Perl
<danperl at> writes
>I was not thinking of actually removing code.  The analogy to C++
>preprocessing was just an example.  I am looking at something that can be
>determined at run-time, not compile-time.
>And you're right, I'm not really concerned about the overhead of an "if"
>because I will not use this extensively anyway.  This problem occurred to me
>when I decided to add an import for win32traceutil.  I'm looking for a way
>to have that permanently in the code and enabling/disabling it only at
>I have thought of alternatives like an environment variable or a
>configuration parameter, but I was looking for other ideas.  I thought this
>should be a common issue and that there could be an idiom for it.
>PS: in the case of importing win32traceutil, I guess that checking the
>environment would be necessary anyway, or the import should be in a try
>statement, ignoring the exceptions.
>"Larry Bates" <lbates at> wrote in message
>news:wfmdnXvIef4v1cHcRVn-vQ at
>> Dan Perl wrote:
>>> Is there a mechanism or an idiom for adding code for debugging so that it
>>> can easily be removed in the production code?  I am thinking of something
>>> similar to the C/C++ preprocessor statements with which you can compile
>>> an application with the debug code or without it (the default).
>>> Dan
>> Personally I think you should consider NOT removing the debugging code.
>> It never ceases to amaze me how many times I must have a client run
>> the application with debug set so that the program logs details about
>> the running process and intermediate results.  The output logfile can
>> then be easily emailed, faxed, etc. to me so that I can determine what
>> is REALLY the problem.  The overhead of these if _debug: "type"
>> statements seems incredibly low compared to the ability to get this
>> information when needed.  Just some thoughts based on my experience
>> of the last 30+ years.
>> Larry Bates
>> Syscon, Inc.

I' use the following technique.  I originally wrote it four years or so
ago, so I'm sure it could be much improved.  In fact looking at it now,
I ma deeply embarrassed to post it, and know it could be dramatically
improved both by using more modern features of Python,  by better coding
and by some comprehension of  design.

I have a module which contains my common functions and I
import this in every module, plus a wrapper for the debug function:

import utility

debug = 0

def dprint( *args):
        print function toggled on or off by module debug variable
    global debug
    if debug:

This allows me to scatter dprint functions throughout the module instead
of print statements, and enable or suppress them by setting the global
'debug', e.g.

    def func(x):
        global total
        total += x
        dprint("total is currently",total)

to get an output of something like:
    ! in func: total is currently 10

The relevant code from my is attached.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: utility
URL: <>
-------------- next part --------------

I would welcome rewrites of this code, of course.


Ian Parker

More information about the Python-list mailing list