(continued from previous page) $ 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 version : 1 formatters : simple : format :'%(asctime)s -%(name)s -%(levelname)s -%(message)s ' (continues on next page) 11 Here’s an example of the same configuration as above, in YAML format for the new dictionary-based approach: The output is nearly identical to that of the non-config-file-based example: 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. 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). 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}$. 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. [logger_simpleExample] level =DEBUG handlers=consoleHandler qualname =simpleExample propagate=0 [handler_consoleHandler] class=StreamHandler level =DEBUG formatter=simpleFormatter args=(sys.stdout,) [formatter_simpleFormatter] format=%(asctime)s - %(name)s - %(levelname)s - %(message)s datefmt=