Updated to incorporate suggestions made by Terry Reedy.
This commit is contained in:
parent
d30960344b
commit
1356583428
31
pep-0391.txt
31
pep-0391.txt
|
@ -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.
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue