idiom for debug code? [1/1]

[Ian Parker]

In message <6tadnfHqDdcg9cHcRVn-hQ at rogers.com>, Dan Perl
<danperl at rogers.com> 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
>run-time.
>
>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.
>
>Dan
>
>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 syscononline.com> wrote in message
>news:wfmdnXvIef4v1cHcRVn-vQ at comcast.com...
>> 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 utility.py 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:
        apply(utility._dprint,args)


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:
    ! module.py:83 in func: total is currently 10


The relevant code from my utility.py is attached.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: utility debug.py
URL: <http://mail.python.org/pipermail/python-list/attachments/20041002/ae992add/attachment.ksh>
-------------- next part --------------

I would welcome rewrites of this code, of course.

Regards

Ian
-- 
Ian Parker