[logger_simpleExample] level =DEBUG handlers=consoleHandler qualname =simpleExample propagate=0 

[handler_consoleHandler] class=StreamHandler level =DEBUG formatter=simpleFormatter args=(sys.stdout,) 

(continued from previous page) 

[formatter_simpleFormatter] format=%(asctime)s - %(name)s - %(levelname)s - %(message)s datefmt= 

The output is nearly identical to that of the non-config-file-based example: 

$ python simple_logging_config.py 2005-03-19 15:38:55,977 - simpleExample - DEBUG - debug message 2005-03-19 15:38:55,979 - simpleExample - INFO - info message 2005-03-19 15:38:56,054 - simpleExample - WARNING - warn message 2005-03-19 15:38:56,055 - simpleExample - ERROR - error message 2005-03-19 15:38:56,130 - simpleExample - CRITICAL - critical 

You can see that the config file approach has a few advantages over the Python code approach, mainly separation of configuration and code and the ability of noncoders to easily modify the logging properties. 

Warning: The fileConfig() function takes a default parameter, disable_existing_loggers , which defaults to$_{True}$ for reasons of backward compatibility. This may or may not be what you want, since it will cause any non-root loggers existing before the$_{fileConfig()}$ call to be disabled unless they (or an ances- tor) are explicitly named in the configuration. Please refer to the reference documentation for more information, and specify$_{False}$ for this parameter if you wish. 

The dictionary passed to $_{dictConfig()}$can also specify a Boolean value with key disable_existing_loggers , which if not specified explicitly in the dictionary also defaults to be- ing interpreted as$_{True}$. This leads to the logger-disabling behaviour described above, which may not be what you want - in which case, provide the key explicitly with a value of$_{False}$. 

Note that the class names referenced in config files need to be either relative to the logging module, or absolute val- ues which can be resolved using normal import mechanisms. Thus, you could use either$_{WatchedFileHandler}$ (relative to the logging module) or mypackage.mymodule.MyHandler (for a class defined in package $_{mypackage}$and module$_{mymodule}$ , where$_{mypackage}$is available on the Python import path). 

In Python 3.2, a new means of configuring logging has been introduced, using dictionaries to hold configuration information. This provides a superset of the functionality of the config-file-based approach outlined above, and is the recommended configuration method for new applications and deployments. Because a Python dictionary is used to hold configuration information, and since you can populate that dictionary using different means, you have more options for configuration. For example, you can use a configuration file in JSON format, or, if you have access to YAML processing functionality, a file in YAML format, to populate the configuration dictionary. Or, of course, you can construct the dictionary in Python code, receive it in pickled form over a socket, or use whatever approach makes sense for your application. 

Here’s an example of the same configuration as above, in YAML format for the new dictionary-based approach: 

version : 1 formatters : simple : format :'%(asctime)s -%(name)s -%(levelname)s -%(message)s ' 

(continues on next page) 

