idiom for debug code?

[Larry Bates]

Dan Perl wrote:
> 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. 
> 
> 
> 

Dan,

You have 3 choices:

1) Interrogate the environment to see what needs to be done.  Like
figuring out you are on Windows do one thing, on Linux something else.
sys.platform comes in handy for this choice.

2) Arguments to the processor (e.g. program -W).  Then you can do
different things depending on the arguments.  I use getopt to pick
these up.

3) Entries in .INI file.  I use this a LOT.  Entries to turn on
tracing, set my debug level, saving default paths, etc. can easily
be set in configuration files (see ConfigParser).  I actually use
config files AND arguments on the processor call simultaneously.
Processor call arguments override anything in the .INI file.
I have code that has thousands of lines of if _debug > 1: dosomething
and just don't see any performance problems.

Larry Bates
Syscon, Inc.