> 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 code anyway. 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... Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
