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'
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.
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.
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.
History
Date
User
Action
Args
2022-04-11 14:57:20
admin
set
github: 56871
2011-08-05 20:46:45
lukasz.langa
set
status: open -> closedresolution: rejectedmessages: +
