[issue16110] Provide logging.config.configParserConfig

[thbach]

New submission from thbach:

Currently logging.config provides a fileConfig function which reads a ini-style 
file via configparser.ConfigParser. I would like to have a function e.g. 
configParserConfig which accepts a ConfigParser instance and configures logging 
directly from the settings found in there. The main reasons for this are:

1) I think it is rather common for an application that provides an interface to 
configure its logging via an ini file to use this ini file also for further 
application configuration. With the current implementation the file is read 
twice and ConfigParser is initialized two times.

2) Currently it is not idiomatic how to alter an ini-file configuration e.g. by 
options passed in via command-line. The new function provides a clear solution: 
create a ConfigParser instance, parse the ini file, alter the configuration and 
pass it on to logging.config.configParserConfig.

In fact, the new functionality is easy to achieve by refactoring logging.config 
a bit (see attached patch).

--
components: Library (Lib)
files: configParserConfig.patch
keywords: patch
messages: 171812
nosy: thbach
priority: normal
severity: normal
status: open
title: Provide logging.config.configParserConfig
Added file: http://bugs.python.org/file27386/configParserConfig.patch

___
Python tracker 
<http://bugs.python.org/issue16110>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16110] Provide logging.config.configParserConfig

[thbach]

thbach added the comment:

vinay: I understand your preference of dictConfig over fileConfig as 
maintainer. But as an application developer I want to provide my user an easy 
way to adjust logging herself. In the end of the day she is the one knowing 
what has to be logged in which place. Therefor, having something like 
fileConfig is essential.

david: The modified configuration can be passed to fileConfig via a StringIO 
instance. 

The downside is that ConfigParser instances with e.g. 'allow_no_value' set to 
True are currently difficult to handle – e.g.:

>>> sys.version
'3.2.3 (default, Jun 25 2012, 23:10:56) \n[GCC 4.7.1]'
>>> cp = configparser.ConfigParser(allow_no_value=True)
>>> cp.read_string('[foo]\nbar')
>>> buf = io.StringIO()
>>> cp.write(buf)
>>> buf.seek(0)
0
>>> logging.config.fileConfig(buf)
---
ParsingError  Traceback (most recent call last)
 in ()
> 1 logging.config.fileConfig(buf)

/usr/lib/python3.2/logging/config.py in fileConfig(fname, defaults, 
disable_existing_loggers)
 64 cp = configparser.ConfigParser(defaults)
 65 if hasattr(fname, 'readline'):
---> 66 cp.read_file(fname)
 67 else:
 68 cp.read(fname)

/usr/lib/python3.2/configparser.py in read_file(self, f, source)
706 except AttributeError:
707 source = ''
--> 708 self._read(f, source)
709 
710 def read_string(self, string, source=''):

/usr/lib/python3.2/configparser.py in _read(self, fp, fpname)
   1079 # if any parsing errors occurred, raise an exception
   1080 if e:
-> 1081 raise e
   1082 self._join_multiline_values()
   1083 

ParsingError: Source contains parsing errors: 
[line  2]: 'bar\n'

Hence, logging.config.fileConfig should at least provide a way to pass in 
arguments for the ConfigParser initialization. Anyways, I think it is much 
cleaner to provide a function which gets the configuration directly from the 
ConfigParser instance.

--

___
Python tracker 
<http://bugs.python.org/issue16110>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com