8000 Add support for duplicate options in configparser · Issue #56871 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

Add support for duplicate options in configparser #56871

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.

Sign up for GitHub

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

Jump to bottom
Closed
ojab mannequin opened this issue Jul 31, 2011 · 6 comments
Closed

Add support for duplicate options in configparser #56871

ojab mannequin opened this issue Jul 31, 2011 · 6 comments
Assignees
@ambv
Labels
stdlib Python modules in the Lib dir type-feature A feature request or enhancement

Comments

@ojab
Copy link
Mannequin
ojab mannequin commented Jul 31, 2011
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']
@ojab
Copy link
Mannequin Author
ojab mannequin commented 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'

@ojab ojab mannequin added stdlib Python modules in the Lib dir type-feature A feature request or enhancement labels Jul 31, 2011
@merwok
Copy link
Member
merwok commented 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?

@merwok merwok changed the title Allow configparser to process suplicate options Add support for duplicate options in configparser Aug 5, 2011
@ojab
Copy link
Mannequin Author
ojab mannequin commented 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
Copy link
Member

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
Copy link
Mannequin Author
ojab mannequin commented Aug 5, 2011

It may be impelmented as configparser.ConfigParser(strict=yes|no|multiline), so no existing configs will be broken.

@ambv
Copy link
Contributor
ambv commented 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 strict option, 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.

@ambv ambv closed this as completed Aug 5, 2011
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
This was referenced Jul 30, 2023
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ambv ambv

Labels
stdlib Python modules in the Lib dir type-feature A feature request or enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ambv @briancurtin @merwok
0