Updated to incorporate suggestions made by Terry Reedy.

This commit is contained in:
Vinay Sajip 2009-11-26 07:57:39 +00:00
parent d30960344b
commit 1356583428
1 changed files with 17 additions and 14 deletions

View File

@ -51,11 +51,11 @@ considered an integral part of the application configuration.
Although the standard library does not contain YAML support at Although the standard library does not contain YAML support at
present, support for both JSON and YAML can be provided in a common present, support for both JSON and YAML can be provided in a common
way because both of these serialization formats allow deserialization way because both of these serialization formats allow deserialization
of Python dictionaries. to Python dictionaries.
By providing a way to configure logging by passing the configuration By providing a way to configure logging by passing the configuration
in a dictionary, logging will be easier to configure not only for in a dictionary, logging will be easier to configure not only for
users of JSON and/or YAML, but also for users of bespoke configuration users of JSON and/or YAML, but also for users of custom configuration
methods, by providing a common format in which to describe the desired methods, by providing a common format in which to describe the desired
configuration. configuration.
@ -90,12 +90,11 @@ used by logging.
API API
--- ---
The logging.config module will have the following additions: The logging.config module will have the following addition:
* A function, called ``dictConfig()``, which takes a single argument * A function, called ``dictConfig()``, which takes a single argument
- the dictionary holding the configuration. Nothing will be - the dictionary holding the configuration. Exceptions will be
returned, though exceptions will be raised if there are errors while raised if there are errors while processing the dictionary.
processing the dictionary.
It will be possible to customize this API - see the section on `API It will be possible to customize this API - see the section on `API
Customization`_. `Incremental configuration`_ is covered in its own Customization`_. `Incremental configuration`_ is covered in its own
@ -117,7 +116,7 @@ The schema is intended to describe a set of logging objects - loggers,
handlers, formatters, filters - which are connected to each other in handlers, formatters, filters - which are connected to each other in
an object graph. Thus, the schema needs to represent connections an object graph. Thus, the schema needs to represent connections
between the objects. For example, say that, once configured, a between the objects. For example, say that, once configured, a
particular logger has an attached to it a particular handler. For the particular logger has attached to it a particular handler. For the
purposes of this discussion, we can say that the logger represents the purposes of this discussion, we can say that the logger represents the
source, and the handler the destination, of a connection between the source, and the handler the destination, of a connection between the
two. Of course in the configured objects this is represented by the two. Of course in the configured objects this is represented by the
@ -183,8 +182,9 @@ the system will not know how to do this. In order to provide complete
flexibility for user-defined object instantiation, the user will need flexibility for user-defined object instantiation, the user will need
to provide a 'factory' - a callable which is called with a to provide a 'factory' - a callable which is called with a
configuration dictionary and which returns the instantiated object. configuration dictionary and which returns the instantiated object.
This will be signalled by the factory being made available under the This will be signalled by an absolute import path to the factory being
special key ``'()'``. Here's a concrete example:: made available under the special key ``'()'``. Here's a concrete
example::
formatters: formatters:
brief: brief:
@ -232,10 +232,13 @@ configuration sub-dictionary for the third formatter, with id
and this contains the special key ``'()'``, which means that and this contains the special key ``'()'``, which means that
user-defined instantiation is wanted. In this case, the specified user-defined instantiation is wanted. In this case, the specified
factory callable will be located using normal import mechanisms and factory callable will be used. If it is an actual callable it will be
called with the *remaining* items in the configuration sub-dictionary used directly - otherwise, if you specify a string (as in the example)
as keyword arguments. In the above example, the formatter with id the actual callable will be located using normal import mechanisms.
``custom`` will be assumed to be returned by the call:: The callable will be called with the *remaining* items in the
configuration sub-dictionary as keyword arguments. In the above
example, the formatter with id ``custom`` will be assumed to be
returned by the call::
my.package.customFormatterFactory(bar='baz', spam=99.9, answer=42) my.package.customFormatterFactory(bar='baz', spam=99.9, answer=42)
@ -618,7 +621,7 @@ The existing socket listener implementation will be modified as
follows: when a configuration message is received, an attempt will be follows: when a configuration message is received, an attempt will be
made to deserialize to a dictionary using the json module. If this made to deserialize to a dictionary using the json module. If this
step fails, the message will be assumed to be in the fileConfig format step fails, the message will be assumed to be in the fileConfig format
and processed as before. If serialization is successful, then and processed as before. If deserialization is successful, then
``dictConfig()`` will be called to process the resulting dictionary. ``dictConfig()`` will be called to process the resulting dictionary.