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

[Glenn Linderman]

On 12/27/2010 11:53 PM, Nick Coghlan wrote:
> However, rather than a manually maintained list of low level loggers,

Yes, a manually maintained list would be bad.

> it may be feasible to just have a flag we can set on loggers that
> makes them immune to the default implicit disabling. Then the config
> calls can support three levels of logger disabling:
> - leave all existing loggers enabled (existing option)
> - leave only flagged loggers enabled (new default behaviour)
> - disable all loggers not mentioned explicitly (new option)

I thought of the idea of a flag to make loggers immune, but it seemed it 
could lead to an arms race, where the knee-jerk reaction of discovering 
that a library's logger got disabled would be to set the flag, and, of 
course, the knee-jerk reaction of discovering that a library's logger 
produced an unwanted message would cause the application to use the new 
option, to "turn them all off again".  Then a new library logger option, 
to become immune to the new disable them all option, would be 
requested.  Etc.

That's why I suggested a list, although perhaps your scheme would be 
"more" backward compatible, as it defines a meaning for the default 
behavior that sounds somewhat similar to the current default 
behavior.... but isn't, really.

Interesting that you choose to disable all loggers not mentioned 
explicitly (a logger white list), whereas I suggested listing the ones 
to disable (a logger black list).

I suppose you suggested the white list, figuring that the application 
could choose which messages it wishes to see.

I chose a black list, figuring that new messages being introduced might 
be useful to the application, but if they never see them (because they 
are not in the white list), they wouldn't know about them.  Of course, 
either scheme can be programmed around, given an obtainable list of 
defined loggers.... but, thinking about it more, maybe that list cannot 
be obtainable, at xxxConfig time, because not all the modules that have 
loggers have been loaded yet... so maybe the question is not just what 
to do with pre-existing loggers at xxxConfig time, but also what to do 
with loggers created in the future that are not configured explicitly?

I can see where a white list would produce a more predictable, 
consistent set of known messages, and a black list would allow 
introduction of new messages (if the lists are both manually maintained, 
vs. programmatically adjusted to a specific white or black list), which 
could be disruptive to some applications... but perhaps shouldn't be.

But a new version of a module on the logger white list could introduce 
new messages, so that is not much different than a new version of a 
module not on the logger black list introducing new messages.  
Applications that use logging, really should be prepared for new 
messages to be displayed.  Testing won't discover them all, disabling 
them could result in useful messages being suppressed.  Should a 
module's documentation be expected to include lists of log messages that 
it may produce at any level of logging?

It really seems that applications that use logging should be prepared to 
discover messages in the log that they don't produce, and that an 
explicit configuration of the appropriate level should be done in the 
xxxConfig call for each logger.... and if they are not mentioned in the 
xxxConfig call, how much logging should they be allowed to do?  Should 
their existence, and lack of configuration be logged?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101228/99f180ae/attachment.html>