-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide logging.config.configParserConfig #60314
Comments
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:
In fact, the new functionality is easy to achieve by refactoring logging.config a bit (see attached patch). |
Thanks for the suggestion - I'm sorry, but I'm not inclined to add this. My reasoning is as follows:
I hope you will agree. I'll leave the issue as pending for now, and close it in a day or two. |
Vinay, you missed one use case in his request: reading the program's configuration, *modifying it* (based on command line args), and then passing it to logging. How would you suggest he handle that use case? Is there an easy way to get from a loaded configuration file to a dictionary for use in dictConfig? |
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)
<ipython-input-67-0717fe665796> in <module>()
----> 1 logging.config.fileConfig(buf) /usr/lib/python3.2/logging/config.py in fileConfig(fname, defaults, disable_existing_loggers) /usr/lib/python3.2/configparser.py in read_file(self, f, source) /usr/lib/python3.2/configparser.py in _read(self, fp, fpname) ParsingError: Source contains parsing errors: <???> 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. |
I could consider relaxing the parameters on fileConfig such that instead of accepting just a string or a file-like object, it additionally accepts a ConfigParser instance. More specifically: def fileConfig(file_or_fname_or_cp, defaults=None):
if isinstance(file_or_fname_or_cp, RawConfigParser):
cp = file_or_filename_or_cp
else:
cp = ConfigParser.ConfigParser(defaults)
if hasattr(cp, 'readfp') and\
hasattr(file_or_fname_or_cp, 'readline'):
cp.readfp(file_or_fname_or_cp)
else:
cp.read(file_or_fname_or_cp)
formatters = _create_formatters(cp) This will only require (in addition to the above) small tweaks to docs |
Yeah, the change you suggest sounds reasonable. Thanks for reconsidering the case! |
New changeset ce0d0d052494 by Vinay Sajip in branch 'default': |
New changeset 113341605247 by R David Murray in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: