Gary Jefferson wrote:
> Thanks for the reply Vinay. I had been reading those docs prior to
> posting, but addFilter/removeFilter only work on individual logger
> instances and handlers. I want to globally enable/disable multiple
> logger instances, based on their namespaces (see the example I
> provided). I cannot find a way to do this. I can certainly call
> addFilter on every instance of every logger throughout the source code,
> but this is more than inconvenient -- it breaks when new modules are
> added with their own loggers in their own namespaces (until fixed by
> manually adding addFilter() to those instances).
>
> e.g., suppose you have a source tree with a several components that do
> network access, and several components that do other things like saving
> state to disk, accessing the filesystem, etc. And suppose you find a
> bug that you think is in the networking code. It would be nice to be
> able to GLOBALLY enable just the loggers that belong in the networking
> namespace, and disable all others (similar to how Filters are supposed
> to work for individual loggers). And then to be able to do this with
> any component, by providing, for example, a command line switch or
> environment variable. Otherwise, the poor programmer is forced to go
> and edit every module in the source tree to selectively turn on/off
> their respecitve loggers. Or am I missing something really obvious
> about how this is done with the logging module?
I don't know enough about your target environment and application to
necessarily give you the best advice, but I'll make some general
comments which I hope are useful. You seem to be thinking that loggers
are binary - i.e. you turn them on or off. But they can be controlled
more finely than that; you should be able to get the effect that you
want by using the different logging levels available judiciously, as
well as using the fact that loggers inhabit a named hierarchy. Note
that loggers, by default, inherit the level of the first ancestor
logger which has an explicitly set level (by ancestor, I mean in the
name hierarchy). The root logger's default level is WARNING, so by
default all loggers will work at this level. [N.B. You can also set
levels for individual handlers, e.g. to ensure that only CRITICAL
conditions are emailed to a specified email address using SMTPHandler,
or that ERROR conditions and above are written to file but not to
console.]
So, for your networking scenario, let's suppose you do the following:
Have all network loggers live in the hierarchy namespace below
"network" (e.g. "network", "network.tcp", "network.http" etc.). By
default, all of these will only log events of severity WARNING and
above. Also, suppose you log events in your application code, which are
sometimes but not always of interest, at level DEBUG or level INFO.
Then, these events will never show up in the logging output, since they
are below WARNING in severity. Subsequently, if you want to turn on
logging verbosity for the network code only, you can arrange, via a
command-line switch or environment variable or configuration file, to
do
logging.getLogger("network").setLevel(logging.DEBUG)
whereupon you will start seeing events from the networking code at
severity DEBUG and INFO. This will affect all loggers in the "network"
hierarchy whose levels you have not explicitly set (so that they will
get the effective level of the first ancestor which has a level
explicitly set - the logger named "network").
If all you are interested in is turning on verbosity based on different
event severities (levels), you should not need to use or set Filters.
Filters are for use only when levels don't meet your use case
requirements.
Best regards,
Vinay Sajip
--
http://mail.python.org/mailman/listinfo/python-list
