selective logger disable/enable

[Gary Jefferson]

Vinay Sajip wrote:
>
> 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


Vinay, okay, I think what you described will work out for me -- thank
you very much for the explanation.

I am still a bit confused about Filters, though.  It seems they are a
bit of an anomoly in the hierarchical view of loggers that the API
supports elsewhere, i.e., filters don't seem to inherit...  Or am I
missing something again?  Here's a quick example:

import logging

log1 = logging.getLogger("top")
log2 = logging.getLogger("top.network")
log3 = logging.getLogger("top.network.tcp")
log4 = logging.getLogger("top.network.http")
log5 = logging.getLogger("top.config")
log6 = logging.getLogger("top.config.file")

logging.basicConfig(level=logging.DEBUG,
        format='%(asctime)s %(levelname)s %(message)s')

filter = logging.Filter("top.network")
log1.addFilter(filter)  # only affects log1, do this for each of log2-7
too?

log1.debug("I'm top")
log2.debug("I'm top.network")
log3.debug("I'm top.network.tcp")
log4.debug("I'm top.network.http")
log5.debug("I'm top.config")
log6.debug("I'm top.config.file")


This is only for the binary case (and I think if I ignore the binary
case and filters altogether as you suggested), but it really would be
nice to be able to squelch /all/ output from loggers that belong to
certain parts of the namespace by using a filter as above (which I
can't get to work).

Perhaps if I set up a basicConfig with a loglevel of nothing, I can get
this to approximate squelching of everything but that which I
explicitly setLevel (which does inherit properly).

In other words, the addFilter/removeFilter part of the API seems rather
impotent if it can't be inherited in the logging namespaces.  In fact,
I can't really figure out a use case where I could possibly want to use
it without it inheriting.  Obviously I'm missing something.  I'm sure
I've consumed more attention that I deserve already in this thread,
but, do you have any pointers which can enlighten me as to how to
effectively use addFilter/removeFilter?

many thanks,
Gary