Repository navigation
Add support for duplicate options in configparser #56871
Description
| BPO | 12662 |
|---|---|
| Nosy | @merwok, @briancurtin, @ambv |
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:
assignee = 'https://github.com/ambv'
closed_at = <Date 2011-08-05.20:46:45.763>
created_at = <Date 2011-07-31.13:09:11.907>
labels = ['type-feature', 'library']
title = 'Add support for duplicate options in configparser'
updated_at = <Date 2011-08-05.20:46:45.762>
user = 'https://bugs.python.org/ojab'bugs.python.org fields:
activity = <Date 2011-08-05.20:46:45.762>
actor = 'lukasz.langa'
assignee = 'lukasz.langa'
closed = True
closed_date = <Date 2011-08-05.20:46:45.763>
closer = 'lukasz.langa'
components = ['Library (Lib)']
creation = <Date 2011-07-31.13:09:11.907>
creator = 'ojab'
dependencies = []
files = []
hgrepos = []
issue_num = 12662
keywords = []
message_count = 6.0
messages = ['141463', '141666', '141676', '141677', '141678', '141688']
nosy_count = 4.0
nosy_names = ['eric.araujo', 'brian.curtin', 'lukasz.langa', 'ojab']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue12662'
versions = ['Python 3.3']
Activity
ojab commentedon Jul 31, 2011
Allow configparser to process duplicate options, just concatenating it's values, so using file
[sect1]
opt1=asd;
opt2=qwe
opt1=fgs
we will have config['sect1']['opt1'] == 'asd;fgs'
merwok commentedon Aug 5, 2011
Thanks for the report. Could you tell us more about the use cases? Are you aware of some config files using this form?
[-]Allow configparser to process suplicate options[/-][+]Add support for duplicate options in configparser[/+]ojab commentedon Aug 5, 2011
There is some [leagcy] proprietary soft-switches, which uses this config format.
Personally I use [hacked] configparser to process Mera systems MVTS/SIP-HIT configs in this format, for example.
briancurtin commentedon Aug 5, 2011
This would break existing config files, including some of my own.
It would also require that you have some end delimiter on every item in order to handle the event that someone duplicates options, otherwise the following would likely behave badly in your application
[sect]
opt=first
opt=second
This would give you "firstsecond" that you'd somehow need to parse. Sometimes if I'm testing out options, like I want to check how "second" works, I'll quickly just do it as above. With a change like this, I couldn't do that, I'd be forced to comment out the first line, or add a delimiter and split on it.
ojab commentedon Aug 5, 2011
It may be impelmented as configparser.ConfigParser(strict=yes|no|multiline), so no existing configs will be broken.
ambv commentedon Aug 5, 2011
This specific config format you're discussing strikes me as error prone and barely useful. With the use case you've given I cannot justify introducing support for it in the standard library. Remember that each switch, variant, however obscure and rarely used, increases source code complexity and introduces a maintenance burden.
As you've seen with the freshly introduced
strictoption, we're generally heading the other direction: to let application users know early they potentially made a misconfiguration that could confuse them later on.So, thanks for your feedback but unfortunately I will have to say no to that proposal.