[Python-Dev] Loggers in the stdlib and logging configuration APIs

[Glenn Linderman]

On 12/27/2010 7:29 AM, Vinay Sajip wrote:
> The logging configuration calls fileConfig and dictConfig disable all existing
> loggers, and enable only loggers explicitly named in the configuration (and
> their children). Although there is a disable_existing_loggers option for each
> configuration API, which can be used to prevent disabling of existing loggers,
> the default value of this option is True (for backward compatibility) and so
> existing ("old") loggers are disabled by default.

Good that you recognized the bigger issue than 10626, and are wanting to 
address it.

It would be interesting to hear the use case for calling fileConfig 
and/or dictConfig and/or basicConfig more than once anyway (although I 
guess basicConfig doesn't disable anything).  That might shed some light 
on the approach that should be taken.

My "intuitive" thought about the matter is that loggers, once enabled, 
shouldn't be disabled except explicitly by name, not implicitly by a 
flag parameter.  So I'd expect a parameter that takes a list of loggers 
to disable, rather than a flag whose default value disables all of 
them.  Of course this doesn't address the how and why of backward 
compatibility needs.

Part of the problem, perhaps, is that stdlib loggers might be enabled 
before the application gets to its logging configuration call, and those 
would then be disabled accidentally.

As I prepare to add logging to my web application this week, I've only 
found the need to initialize logging in one place and at one time... I 
doubt that any of the loggers you mentioned as being in the 3.2 stdlib 
will have been enabled by then, so I'll not have a problem, but if they 
proliferate, I could eventually in future versions.  Granted, my 
application will likely be one of the simpler applications of logging, 
at least initially.

While I agree it would be nice to have a stdlib logger naming convention 
of some sort, I don't think the naming convention should be used to 
implicitly not disable particular loggers.  The only difference between 
stdlib and 3rd party libraries is whether they've become stable enough 
and useful enough for the whole Python community; many 3rd party 
libraries are quite stable enough and useful enough for particular 
applications, and could have similar issues as the stdlib regarding 
logger configuration.

Having an API to disable loggers using an explicit list would require a 
corresponding API to obtain from logging the list of currently enabled 
loggers, and perhaps currently disabled ones as well?  That way, if an 
application truly wanted to disable all currently enabled loggers, they 
would have an easy way to know the list... and perhaps the list of 
loggers they disable during configuration should be the first thing that 
is logged as a result of the xxxConfig API?  Then, at least, they would 
not be ignorant of the accidental disabling.   I guess even if the 
parameter were left as a default flag to turn off all loggers, if the 
list were logged, that would be alerting.  But some applications may not 
expect such a log entry.... but maybe that is the least instrusive 
backwards-compatible action that can be taken, because if an application 
does configure logging, they likely do expect to have log messages to 
view/process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101227/8726d6ee/attachment.html>