[Python-Dev] Loggers in the stdlib and logging configuration APIs (original) (raw)

Glenn Linderman v+python at g.nevcal.com
Tue Dec 28 09:25:36 CET 2010

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>

More information about the Python-Dev mailing list