[Python-Dev] Consistent logging in the standard library

Matthew F. Barnes mfb at lotusland.dyndns.org
Mon Sep 22 20:36:36 EDT 2003


To recap recent discussion on this thread, there seems to be consensus
among those I've spoken to that there should be a namespace in the logging
hierarchy named "python" that is reserved for the standard library, and
that standard library modules and packages should use loggers within this
namespace that are named after themselves (i.e. "python." + __name__). 
For example, the asyncore module should use a logger named
"python.asyncore".  The modules may also define child loggers as needed,
such as "python.asyncore.socket".


This week's topic: Configuration

I tend to think that, at least for Python 2.4, each logger should be
configured to mimic the behavior of the Python 2.3 version of its
corresponding module in terms of message format and destination (e.g.
log-file, sys.stdout, sys.stderr, etc.).

I think it would be nice for each "standard library logger" to default to
such a configuration automatically, while still allowing a configuration
file to customize them.

The issue is where this default configuration should reside and when it
should be applied.  My reference implementation currently has each module
configure its own logger at the end of the module, so that those
statements are executed when the module is imported.  But I'm not
confident that this is the best approach, or even a correct approach.  For
example, consider what would happen if a configuration file that defines a
section for the python.asyncore logger is processed *before* the asyncore
module is imported.

I'm looking for some helpful suggestions from the community.

- What's the best approach for configuring the "standard library loggers",
or should we at all?

- Should the standard library define its own logging configuration file,
and what would be the semantics around that?

- Perhaps the logging API should provide for a way to test whether a
particular logger is defined, so that the modules could check that before
applying their default settings?


Matthew Barnes




More information about the Python-Dev mailing list