idiom for debug code?
danperl at rogers.com
Thu Sep 30 22:12:38 CEST 2004
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 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).
> 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.
More information about the Python-list