idiom for debug code? [1/1]
parker at hiredatum.demon.co.uk
Sun Oct 3 11:50:13 CEST 2004
In message <yeadnZwsvvKa7cLcRVn-pA at rogers.com>, Dan Perl
<danperl at rogers.com> writes
>Thanks, Ian. It's late Saturday for me now so I will look more at the code
>later, but so far what I get from what you sent is only dprint and that is a
>logging utility. That's not what I was looking for. OTOH, I see that your
>posting was probably only a first installment, so I am looking forward to
>more details, including more parts from your utility module.
>The solution that you are using for the dprint utility involves a global
>variable. How do you change its value? Is that still by making a change in
>the code, even if the change is only one place? I would like a solution
>that does not involve any change in the code and is determined strictly at
>run-time. I was thinking of something like an environment variable or a
>configuration attribute. Of course, your solution can be adapted to set the
>global variable based on an environment variable or based on configuration.
>As for rewriting your code, did you take a look at the newsgroup thread
>about the new logging utility?
>"Ian Parker" <parker at hiredatum.demon.co.uk> wrote in message
>news:0DoHajVjBwXBFwhr at hiredatum.demon.co.uk...
>> 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
>>>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
>>>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 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
>>>>> can easily be removed in the production code? I am thinking of
>>>>> similar to the C/C++ preprocessor statements with which you can compile
>>>>> an application with the debug code or without it (the default).
>>>> 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:
>> 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.
>> I would welcome rewrites of this code, of course.
>> Ian Parker
That was indeed the only instalment. Yes, thinking about it now, dprint
is simply a logging system, so I really should look at the logging
module -(which didn't exist when I wrote dprint). Feel free to lift the
code - I certainly lifted chunks of it from other examples I find on
Yes, 'debug' is a global variable. The reason for the inclusion of the
dprint wrapper in each module is to make use of the module 'debug' to
give a little more granularity. Two points:
In a function, I frequently do what feels like a very clumsy hack:
global debug ; olddebug = debug
# debug = 1
debug = olddebug
so that any embedded dprints can be controlled more specifically.
One other feature of dprint: if you call it without parameters it will
attempt to display the arguments of the function in which it occurs.
What other functions do I have in my utility.py? The same as everybody
else - all those things you find yourself writing that you think you
will use often. No I'm not publishing it - the code is frequently even
worse than that of dprint.
More information about the Python-list