Vinay Sajip wrote:
Full View
PEP 391 is, I believe, ready for review.
http://www.python.org/dev/peps/pep-0391/
This is my first reading of this. Comments:
nit: I believe "both of these serialization formats allow
deserialization of Python dictionaries." should be "... to Python
dictionaries."
"bespoke configuration methods" I had to look up this mostly
non-American British word, which I thought meant 'engaged (to be
married, as in spoken for)' to guess that you probably mean the much
more obscure 'custom configuration methods'. If so, please say so (in
plain American ;-)
"The logging.config module will have the following additions:"
There is currently only one addition.
"Nothing will be returned, though exceptions will be raised "
Technically incorrect. "Returns None; exceptions ..." or just
"Exceptions ...". The doc for print(), for instance, just says what is
does and does not mention the default None return.
"particular logger has an attached to it a particular handler."
delete 'an'
" '()' : 'my.package.customFormatterFactory', "
This at first appeared to be a typo. You earlier wrote "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 '()'. " A string is not a callable. So I thought you perhaps meant
" '()' : my.package.customFormatterFactory, " without the quotes, or
" '()' : <<my.package.customFormatterFactory>>, ", where <<object type>>
is understood to be a place filler for an object of the type specified.
Then I see "the specified factory callable will be located using normal
import mechanisms" If you stick with this, then
"This will be signalled by the factory being made available under the
special key '()'."
would be clearer as
"This will be signalled by an absolute import path to the factory being
made available under the special key '()'."
However, if the code that constructs the dict passed to dictConfig() has
the factory in hand, and possibly no absolute import path, why not let
it pass the function directly instead of indirectly. (I am here using
'absolute import path' to mean one that logging can resolve, rather than
being only resolvable from the dictConfig caller.) Being able to do so
is one of the great features of Python. The code for dictConfig could
easily wrap the current import.
if not hasattr(factory, '__call__'): factory = __import__(factory)
"The '()' also serves as a mnemonic that the corresponding value is a
callable." More than just that, parentheses preceeded by an expression
*are* a call operator, mapped to '__call__', just as the addition
operator '+' is mapped to '__add__'. Great choice to me.
...
"If serialization is successful, then dictConfig() will be called to
process the resulting dictionary"
deserialization
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
