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:
|
||||
|
||||
* 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
|
||||
- the dictionary holding the configuration. This 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()
|
||||
- the dictionary holding the configuration. Nothing will be
|
||||
returned, though exceptions will be raised if there are errors
|
||||
while processing the dictionary.
|
||||
|
||||
It will be possible to customize this API - see the section on API
|
||||
customization.
|
||||
|
||||
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
|
||||
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
|
||||
--------------------------
|
||||
|
@ -520,6 +520,49 @@ and is ``True``, the system will ignore any ``formatters``,
|
|||
``level`` and ``propagate`` settings in the ``loggers`` and ``root``
|
||||
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
|
||||
====================
|
||||
|
@ -540,6 +583,7 @@ incomplete) list of conditions which will raise an error:
|
|||
|
||||
* Inability to resolve to an internal or external object
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
|
|
Loading…
Reference in New Issue