idiom for debug code? [1/1]

[Dan Perl]

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?

Dan

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


--------------------------------------------------------------------------------


>
> I would welcome rewrites of this code, of course.
>
> Regards
>
> Ian
> -- 
> Ian Parker
>