[Python-Dev] Stdlib Logging questions (PEP 337 SoC)
vinay_sajip at red-dove.com
Tue Jun 6 20:12:40 CEST 2006
> Are you suggesting that the logging module should ship with a standard
> configuration that does something specific for py.* loggers? Or even
> one that has different handlers for different stdlib modules?
Sorry I'm a little late in to the discussion :-(
I can see people objecting to a "standard" configuration, as there will be
many differing interpretations of what the "standard" should be. Perhaps the
PEP should detail any proposed configuration. The configuration for py.*
loggers, if approved in the PEP, will need to be set up with some care and
probably need to be disabled by default. Once logging is introduced into the
stdlib, the logger hierarchy used by the stdlib modules (e.g.
"py.asyncore.dispatcher.hits", "py.asyncore.dispatcher.messages") will
become something of a backward-compatibility concern. For example, client
code might add handlers to specific portions of the hierarchy, and while
adding "child" loggers to existing levels will be OK, removing or renaming
parts of the hierarchy will cause client code to not produce the expected
logging behaviour. Having logger names follow package/subpackage/public
class should be OK since those couldn't change without breaking existing
One way of ring-fencing stdlib logging is to have the "py" logger created
with a level of (say) DEBUG and propagate = 0. This way, logging events
raised in stdlib code are not sent to the root logger's handlers, unless
client code explicitly sets the propagate flag to 1. The "py" logger could
be initialised with a bit-bucket handler which does nothing (and avoids the
"No handlers could be found for logger xxx" message). In my view it'd be
best to not add any other handlers in the stdlib itself, leaving that to
user code. With this approach, by default stdlib code will behave as it does
now. Even the verbose setting of DEBUG on the "py" logger will not produce
any output unless user code sets its propagate attribute to 1 or explicitly
adds a handler to it or any of its descendants.
My 2 cents...
More information about the Python-Dev