Conditional based on whether or not a module is being used

[Vinay Sajip]

On Mar 6, 11:13 pm, Pete Emerson <pemer... at gmail.com> wrote:
>
> 1) In debug mode, send what would have gone to syslog to STDOUT or
> STDERR
> 2) In non-debug mode, use /dev/log or localhost:514 depending on what
> is set
> 3) Allow for multiple levels ofloggingbeyond INFO, WARNING, CRIT ...
> essentially allow multiple levels of INFO depending on how much detail
> is desired.  A high level of messaging when programs are running
> poorly is desired, but when programs are running smoothly, I don't
> need to send as much to syslog.


By "debug mode", do you mean the value of the __debug__ variable, or
something else (e.g. a flag in your application)?

You could certainly do something like (in your logging initialization
code):

if __debug__:
   handler = logging.StreamHandler()
else:
   #use domain socket, UDP, etc.
   handler = logging.handlers.SocketHandler(...)
logger.addHandler(handler)

where logger is the root logger or some other high-level logger in
your application.

By the way, are you aware that accessing syslog via openlog etc. may
not thread-safe, at least in some environments? Search the Web for
"syslog openlog thread" for more info.

You can certainly add additional levels to logging (see addLevelName),
but I'm not sure that's what you really need. Generally, I find that
when there are problems to be debugged, I get more benefits from using
the logger hierarchy: I keep the level at logging.DEBUG but just log
different things to different loggers. Just as a fr'instance, if I
were logging the parsing of HTTP requests, I might use loggers named
'request', 'request.headers', 'request.headers.cookies',
'request.body', 'request.body.multipart' etc. When everything is
working well, I have the verbosity of these loggers turned low by e.g.
setting the level for the 'request' logger to WARNING or higher; when
I want to debug header processing in more detail I might set the level
of the 'request.headers' logger to DEBUG, which would output events
from request header processing (but not the body), or just turn up the
'request.headers.cookies' level to look in more detail at what's
happening during processing "Cookie:" headers.

Regards,

Vinay Sajip