Example:

# Step 1, Create log manager and configure it
prog_name = 'my_app'
log_mgr = LogManager(prog_name)
log_mgr.configure(dict(verbose=True))

# Step 2, Create handlers
log_mgr.create_log_handlers([dict(name='my_app stdout',
                                  stream=sys.stdout,
                                  level=logging.INFO),
                             dict(name='my_app file',
                                  filename='my_app.log',
                                  level=logging.DEBUG)])

# Step 3, Create and use a logger in your code
class FooBar:
    def __init__(self, name):
        log_mgr.get_logger(self, True)
        self.info("I'm alive! %s", name)

foobar = FooBar('Dr. Frankenstein')

# Dump the log manager state for illustration
print
print log_mgr

Running the above code would produce:

<INFO>: I'm alive! Dr. Frankenstein

root_logger_name: my_app
configure_state: None
default_level: INFO
debug: False
verbose: True
number of loggers: 2
    "my_app" [level=INFO]
    "my_app.__main__.FooBar" [level=INFO]
number of handlers: 2
    "my_app file" [level=DEBUG]
    "my_app stdout" [level=INFO]
number of logger regexps: 0

Note, Steps 1 & 2 were broken out for expository purposes. You can pass your handler configuration into LogManager.configure(). The above could have been simpler and more compact.:

# Step 1 & 2, Create log manager, and configure it and handlers
prog_name = 'my_app'
log_mgr = LogManager(prog_name)
log_mgr.configure(dict(verbose=True,
                       handlers = [dict(name='my_app stdout',
                                        stream=sys.stdout,
                                        level=logging.INFO),
                                   dict(name='my_app file',
                                        filename='my_app.log',
                                        level=logging.DEBUG)])

Understanding when & how log messages are emitted:

Loggers provide the application interface for logging. Every logger object has the following methods debug(), info(), warning(), error(), critical(), exception() and log() all of which can accept a format string and arguments. Applications generate logging messages by calling one of these methods to produce a formatted message.

A logger's effective level is the first explicitly set level found when searching from the logger through it's ancestors terminating at the root logger. The root logger always has an explicit level (defaults to WARNING).

For a message to be emitted by a handler the following must be true:

The logger's effective level must >= message level and it must not be filtered by a filter attached to the logger, otherwise the message is discarded.

If the message survives the logger check it is passed to a list of handlers. A handler will emit the message if the handler's level >= message level and its not filtered by a filter attached to the handler.

The list of handlers is determined thusly: Each logger has a list of handlers (which may be empty). Starting with the logger the message was bound to the message is passed to each of it's handlers. Then the process repeats itself by traversing the chain of loggers through all of it's ancestors until it reaches the root logger. The logger traversal will be terminated if the propagate flag on a logger is False (by default propagate is True).

Let's look at a hypothetical logger hierarchy (tree):

    A
   / \
  B   D
 /
C

There are 4 loggers and 3 handlers

Loggers:

Logger	Level	Filters	Propagate	Handlers
A	WARNING	[]	False	[h1,h2]
A.B	ERROR	[]	False	[h3]
A.B.C	DEBUG	[]	True
A.D		[]	True

Handlers:

Handler	Level	Filters
h1	ERROR	[]
h2	WARNING	[]
h3	DEBUG	[]

Each of the loggers and handlers have empty filter lists in this example thus the filter checks will always pass.

If a debug message is posted logger A.B.C the following would happen. The effective level is determined. Since it does not have a level set it's parent (A.B) is examined which has ERROR set, therefore the effective level of A.B.C is ERROR. Processing immediately stops because the logger's level of ERROR does not permit debug messages.

If an error message is posted on logger A.B.C it passes the logger level check and filter check therefore the message is passed along to the handlers. The list of handlers on A.B.C is empty so no handlers are called at this position in the logging hierarchy. Logger A.B.C's propagate flag is True so parent logger A.B handlers are invoked. Handler h3's level is DEBUG, it passes both the level and filter check thus h3 emits the message. Processing now stops because logger A.B's propagate flag is False.

Now let's see what would happen if a warning message was posted on logger A.D. It's effective level is WARNING because logger A.D does not have a level set, it's only ancestor is logger A, the root logger which has a level of WARNING, thus logger's A.D effective level is WARNING. Logger A.D has no handlers, it's propagate flag is True so the message is passed to it's parent logger A, the root logger. Logger A has two handlers h1 and h2. The level of h1 is ERROR so the warning message is discarded by h1, nothing is emitted by h1. Next handler h2 is invoked, it's level is WARNING so it passes both the level check and the filter check, thus h2 emits the warning message.

How to configure independent logging spaces:

A common idiom is to hang all handlers off the root logger and set the root loggers level to the desired verbosity. But this simplistic approach runs afoul of several problems, in particular who controls logging (accomplished by configuring the root logger). The usual advice is to check and see if the root logger has any handlers set, if so someone before you has configured logging and you should inherit their configuration, all you do is add your own loggers without any explicitly set level. If the root logger doesn't have handlers set then you go ahead and configure the root logger to your preference. The idea here is if your code is being loaded by another application you want to defer to that applications logging configuration but if your code is running stand-alone you need to set up logging yourself.

But sometimes your code really wants it's own logging configuration managed only by yourself completely independent of any logging configuration by someone who may have loaded your code. Even if you code is not designed to be loaded as a package or module you may be faced with this problem. A trivial example of this is running your code under a unit test framework which itself uses the logging facility (remember there is only ever one root logger in any Python process).

Fortunately there is a simple way to accommodate this. All you need to do is create a "fake" root in the logging hierarchy which belongs to you. You set your fake root's propagate flag to False, set a level on it and you'll hang your handlers off this fake root. Then when you create your loggers each should be a descendant of this fake root. Now you've completely isolated yourself in the logging hierarchy and won't be influenced by any other logging configuration. As an example let's say your your code is called 'foo' and so you name your fake root logger 'foo'.:

my_root = logging.getLogger('foo') # child of the root logger
my_root.propagate = False
my_root.setLevel(logging.DEBUG)
my_root.addHandler(my_handler)

Then every logger you create should have 'foo.' prepended to it's name. If you're logging my module your module's logger would be created like this:

module_logger = logging.getLogger('foo.%s' % __module__)

If you're logging by class then your class logger would be:

class_logger = logging.getLogger('foo.%s.%s' % (self.__module__,  self.__class__.__name__))

How to set levels:

An instinctive or simplistic assumption is to set the root logger to a high logging level, for example ERROR. After all you don't want to be spamming users with debug and info messages. Let's also assume you've got two handlers, one for a file and one for the console, both attached to the root logger (a common configuration) and you haven't set the level on either handler (in which case the handler will emit all levels).

But now let's say you want to turn on debugging, but just to the file, the console should continue to only emit error messages.

You set the root logger's level to DEBUG. The first thing you notice is that you're getting debug message both in the file and on the console because the console's handler does not have a level set. Not what you want.

So you go back restore the root loggers level back to it's original ERROR level and set the file handler's level to DEBUG and the console handler's level to ERROR. Now you don't get any debug messages because the root logger is blocking all messages below the level of ERROR and doesn't invoke any handlers. The file handler attached to the root logger even though it's level is set to DEBUG never gets a chance to process the message.

IMPORTANT: You have to set the logger's level to the minimum of all the attached handler's levels, otherwise the logger may block the message from ever reaching any handler.

In this example the root logger's level must be set to DEBUG, the file handler's level to DEBUG, and the console handler's level set to ERROR.

Now let's take a more real world example which is a bit more complicated. It's typical to assign loggers to every major class. In fact this is the design strategy of Java logging from which the Python logging is modeled. In a large complex application or library that means dozens or possibly hundreds of loggers. Now lets say you need to trace what is happening with one class. If you use the simplistic configuration outlined above you'll set the log level of the root logger and one of the handlers to debug. Now you're flooded with debug message from every logger in the system when all you wanted was the debug messages from just one class.

How can you get fine grained control over which loggers emit debug messages? Here are some possibilities: