Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Checkins

r76533 - peps/trunk/pep-0391.txt

 

 

Python checkins RSS feed   Index | Next | Previous | View Threaded


python-checkins at python

Nov 26, 2009, 12:20 AM

Post #1 of 1 (128 views)
Permalink
r76533 - peps/trunk/pep-0391.txt

Author: vinay.sajip
Date: Thu Nov 26 08:57:39 2009
New Revision: 76533

Log:
Updated to incorporate suggestions made by Terry Reedy.

Modified:
peps/trunk/pep-0391.txt

Modified: peps/trunk/pep-0391.txt
==============================================================================
--- peps/trunk/pep-0391.txt (original)
+++ peps/trunk/pep-0391.txt Thu Nov 26 08:57:39 2009
@@ -51,11 +51,11 @@
Although the standard library does not contain YAML support at
present, support for both JSON and YAML can be provided in a common
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
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
configuration.

@@ -90,12 +90,11 @@
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
- - the dictionary holding the configuration. Nothing will be
- returned, though exceptions will be raised if there are errors while
- processing the dictionary.
+ - the dictionary holding the configuration. 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`_. `Incremental configuration`_ is covered in its own
@@ -117,7 +116,7 @@
handlers, formatters, filters - which are connected to each other in
an object graph. Thus, the schema needs to represent connections
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
source, and the handler the destination, of a connection between the
two. Of course in the configured objects this is represented by the
@@ -183,8 +182,9 @@
flexibility for user-defined object instantiation, the user will need
to provide a 'factory' - a callable which is called with a
configuration dictionary and which returns the instantiated object.
-This will be signalled by the factory being made available under the
-special key ``'()'``. Here's a concrete example::
+This will be signalled by an absolute import path to the factory being
+made available under the special key ``'()'``. Here's a concrete
+example::

formatters:
brief:
@@ -232,10 +232,13 @@

and this contains the special key ``'()'``, which means that
user-defined instantiation is wanted. In this case, the specified
-factory callable will be located using normal import mechanisms and
-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::
+factory callable will be used. If it is an actual callable it will be
+used directly - otherwise, if you specify a string (as in the example)
+the actual callable will be located using normal import mechanisms.
+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)

@@ -618,7 +621,7 @@
follows: when a configuration message is received, an attempt will be
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
-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.


_______________________________________________
Python-checkins mailing list
Python-checkins [at] python
http://mail.python.org/mailman/listinfo/python-checkins

Python checkins RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.