Incorporated comments by Jim Jewett.
This commit is contained in:
parent
919266de7a
commit
0a6fd7e40c
76
pep-0391.txt
76
pep-0391.txt
|
@ -92,24 +92,13 @@ API
|
||||||
|
|
||||||
The logging.config module will have the following additions:
|
The logging.config module will have the following additions:
|
||||||
|
|
||||||
* A class, called ``DictConfigurator``, whose constructor is passed
|
|
||||||
the dictionary used for configuration, and which has a
|
|
||||||
``configure()`` method.
|
|
||||||
|
|
||||||
* A callable, called ``dictConfigClass``, which will (by default) be
|
|
||||||
set to ``DictConfigurator``. This is provided so that if desired,
|
|
||||||
``DictConfigurator`` can be replaced with a suitable user-defined
|
|
||||||
implementation.
|
|
||||||
|
|
||||||
* A function, called ``dictConfig()``, which takes a single argument
|
* A function, called ``dictConfig()``, which takes a single argument
|
||||||
- the dictionary holding the configuration. This function will
|
- the dictionary holding the configuration. Nothing will be
|
||||||
call ``dictConfigClass`` passing the specified dictionary, and then
|
returned, though exceptions will be raised if there are errors
|
||||||
call the ``configure()`` method on the returned object to actually
|
while processing the dictionary.
|
||||||
put the configuration into effect::
|
|
||||||
|
|
||||||
def dictConfig(config):
|
|
||||||
dictConfigClass(config).configure()
|
|
||||||
|
|
||||||
|
It will be possible to customize this API - see the section on API
|
||||||
|
customization.
|
||||||
|
|
||||||
Dictionary Schema - Overview
|
Dictionary Schema - Overview
|
||||||
----------------------------
|
----------------------------
|
||||||
|
@ -333,6 +322,17 @@ index value consists only of decimal digits, access will be attempted
|
||||||
using the corresponding integer value, falling back to the string
|
using the corresponding integer value, falling back to the string
|
||||||
value if needed.
|
value if needed.
|
||||||
|
|
||||||
|
Given a string ``int://handlers.myhandler.mykey.123``, this will
|
||||||
|
resolve to ``config_dict['handlers']['myhandler']['mykey']['123']``.
|
||||||
|
If the string is specified as ``int://handlers.myhandler.mykey[123]``,
|
||||||
|
the system will attempt to retrieve the value from
|
||||||
|
``config_dict['handlers']['myhandler']['mykey'][123]``, ad fall back
|
||||||
|
to ``config_dict['handlers']['myhandler']['mykey']['123']`` if that
|
||||||
|
fails.
|
||||||
|
|
||||||
|
Note: the ``ext`` and ``int`` prefixes are provisional. If better
|
||||||
|
alternatives are suggested during the PEP review process, they will be
|
||||||
|
used.
|
||||||
|
|
||||||
Dictionary Schema - Detail
|
Dictionary Schema - Detail
|
||||||
--------------------------
|
--------------------------
|
||||||
|
@ -520,6 +520,49 @@ and is ``True``, the system will ignore any ``formatters``,
|
||||||
``level`` and ``propagate`` settings in the ``loggers`` and ``root``
|
``level`` and ``propagate`` settings in the ``loggers`` and ``root``
|
||||||
entries.
|
entries.
|
||||||
|
|
||||||
|
It's certainly possible to provide incremental configuration by other
|
||||||
|
means, for example making ``dictConfig()`` take an ``incremental``
|
||||||
|
keyword argument which defaults to ``False``. The reason for
|
||||||
|
suggesting that a flag in the configuration dict be used is that it
|
||||||
|
allows for configurations to be sent over the wire as pickled dicts
|
||||||
|
to a socket listener. Thus, the logging verbosity of a long-running
|
||||||
|
application can be altered over time with no need to stop and
|
||||||
|
restart the application.
|
||||||
|
|
||||||
|
Note: Feedback on incremental configuration needs based on your
|
||||||
|
practical experience will be particularly welcome.
|
||||||
|
|
||||||
|
|
||||||
|
API Customization
|
||||||
|
=================
|
||||||
|
|
||||||
|
The bare-bones ``dictConfig()`` API will not be sufficient for all
|
||||||
|
use cases. Provision for customization of the API will be made by
|
||||||
|
providing the following:
|
||||||
|
|
||||||
|
* A class, called ``DictConfigurator``, whose constructor is passed
|
||||||
|
the dictionary used for configuration, and which has a
|
||||||
|
``configure()`` method.
|
||||||
|
|
||||||
|
* A callable, called ``dictConfigClass``, which will (by default) be
|
||||||
|
set to ``DictConfigurator``. This is provided so that if desired,
|
||||||
|
``DictConfigurator`` can be replaced with a suitable user-defined
|
||||||
|
implementation.
|
||||||
|
|
||||||
|
The ``dictConfig()`` function will call ``dictConfigClass`` passing
|
||||||
|
the specified dictionary, and then call the ``configure()`` method on
|
||||||
|
the returned object to actually put the configuration into effect::
|
||||||
|
|
||||||
|
def dictConfig(config):
|
||||||
|
dictConfigClass(config).configure()
|
||||||
|
|
||||||
|
This should cater to all customization needs. For example, a subclass
|
||||||
|
of ``DictConfigurator`` could call ``DictConfigurator.__init__()`` in
|
||||||
|
its own ``__init__()``, then set up custom prefixes which would be
|
||||||
|
usable in the subsequent ``configure() call``. The ``dictConfigClass``
|
||||||
|
would be bound to the subclass, and then ``dictConfig()`` could be
|
||||||
|
called exactly as in the default, uncustomized state.
|
||||||
|
|
||||||
|
|
||||||
Configuration Errors
|
Configuration Errors
|
||||||
====================
|
====================
|
||||||
|
@ -540,6 +583,7 @@ incomplete) list of conditions which will raise an error:
|
||||||
|
|
||||||
* Inability to resolve to an internal or external object
|
* Inability to resolve to an internal or external object
|
||||||
|
|
||||||
|
|
||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue