configparser accepts invalid keys and sections when writing

[The-Compiler]

BPO	21498
Nosy	@ambv, @The-Compiler, @isidentical

^{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 = None
created_at = <Date 2014-05-13.14:47:29.111>
labels = ['type-bug', 'library']
title = 'configparser accepts keys beginning with comment_chars when writing'
updated_at = <Date 2020-01-11.15:02:37.046>
user = 'https://github.com/The-Compiler'

bugs.python.org fields:

activity = <Date 2020-01-11.15:02:37.046>
actor = 'BTaskaya'
assignee = 'lukasz.langa'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2014-05-13.14:47:29.111>
creator = 'The Compiler'
dependencies = []
files = []
hgrepos = []
issue_num = 21498
keywords = []
message_count = 2.0
messages = ['218463', '359797']
nosy_count = 3.0
nosy_names = ['lukasz.langa', 'The Compiler', 'BTaskaya']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue21498'
versions = []

Linked PRs

• gh-65697: Prevent configparser from writing keys it cannot properly read #129270
• gh-65697: Improved error msg for configparser key validation #135527
• [3.14] gh-65697: Improved error msg for configparser key validation (GH-135527) #135541

[The-Compiler]

When adding something to a configparser instance which has a key beginning with a comment char, it writes the data to a file without generating an error, and when reading the file back obviously the data is different as it's a comment:

>>> import configparser, sys
>>> cp = configparser.ConfigParser()
>>> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>>> cp.write(sys.stdout)
[DEFAULT]
;foo = bar

This was discussed on python-dev here:
https://mail.python.org/pipermail/python-dev/2014-April/134293.html

Of course there are other corner cases as well, like having a key like "[foo]" or "=bar".

I think whatever data I pass into a configparser should also come out again when reading the file back.

Since there's no escaping in configparser, I think the ideal solution would be configparser refusing to write ambigious values.

While this is technically a backwards-incompatible change, applications doing this were broken in the first place, so validation while writing will not break anything.

Validating when setting values would be better of course, but this can potentially break applications where configparser is used without actually writing a file.

[isidentical]

Any update on this? Discussion over Python-Dev looks like finished without a consensus/resolution.

[marc-hb]

#69909 is similar - and much more detailed.

[jaraco]

See also #69909, #67490, #65122, where the prior consensus seems to have been to be lenient to what the user provides, and leave it up to them to provide valid inputs. I can see the flip side that it would be valuable to provide some level of validation and reasonableness checks. However, it appears there are cases where other parsers might accept inputs that Python's configparser might not accept (e.g. section names like [Test[2]_foo] as mentioned in #69909), where it might be valuable for a Python script to be able to generate such outputs even if it can't read it. It won't be possible with a simple implementation to please both users that want to generate idiosyncratic output and those that want to reject it.

I've re-classified this as a feature and not a bug as the current approach is stable and defended and any change is going to be some kind of enhancement.

I think the next thing that needs to happen is to draft a design that addresses the concerns laid out in the various discussions. Such a design should probably start by synthesizing all of the concerns brought up in these different threads (the issues mentioned above and other discussions linked from those). An LLM might be helpful in performing such a synthesis.