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
[doc] Explain ConfigParser 'valid section name' and .SECTCRE #65122
Comments
It would be good if ConfigParser supported angled brackets in section names by being greedy when parsing. For example, section: [Test[2]_foo] gets parsed as: Test[2 |
This is invalid as a bug report, unless one considers that the presence of '_foo]' on the same line should have raised an exception. As an enhancement request, I think it should be rejected. ConfigParser configuration language is based on msdos/windows .ini files. Similar files are used on windows. "A configuration file consists of sections, each led by a [section] header," That and "The section name appears on a line by itself, in square brackets ([ and ])." from |
Thanks for the exhaustive explanation. I did however come across a proprietary application that stores it's configuration in an INI like file that exhibits this corner case behaviour with section names, hence the suggestion for enhancement. |
I see. Perhaps it uses a proprietary .ini reader ;-). |
If this is the intended behaviuour, I guess ConfigParser should warn the user if he supplies a section name with a ']' (prevent failed roundtrips). See http://bugs.python.org/issue23301 The current behaviour looks like the opposite of Postel's law. |
IMHO your rejection is stupid. User input should always be validated. At least a ValueError should be raised if add_section() is called with a string containing ']\x00\n['. As this will always create a broken configuration. Otherwise ConfigParser cannot be used to write new config files without having deeper knowledge about the implementation. |
The enhancement request was rejected. At this point I think it would be better to open a new bug requesting that an error be raised if the supplied section name contains a ']'. The question there is if there are backward compatibility issues. That can be discussed on the new issue you open. |
Sebastian: you have it backwards. A paraphrase of Postel's recommendation (calling it a Law is wrong) is 'accept dirty data, emit clean data'. This is the current behavior. See https://en.wikipedia.org/wiki/Robustness_principle. This article also explains the opposite viewpoint, that dirty data should be rejected, as SpaceOne is suggesting. SpaceOne: unless it is your intention to discourage people from volunteering their time to respond to issues raised on the tracker, you should read what they write more carefully and think more carefully about how you express your opinions. If you really want a ValueError here, open an new enhancement issue for 3.6. |
Sorry about that! |
Terry: I am not so sure about that interpretation. Do we agree that the INI-files are the data/message? ConfigParser refuses to accept dirty INI-Files (with ']' in section names) but will produce this kind of files. |
Why the debate on an issue that was closed over 18 months ago? |
Discussion continues because my close message was, I now realize, incomplete and therefore unsatisfying. Ditto for the doc. So I complete my close message here and reopen issue to augment the doc. The discussion has so far has glossed over the key question: "What is a legal section name?" Pulling the answer from the doc was a challenge. It uses 'legal section name', once, as if one should already know. Reading further, I found the answer: there is no (fixed) answer! The legal section name for a particular parser is determined by its .SECTCRE class attribute. I propose adding near the top of the doc: So my response to Miloš should have been to set SECTCRE to something like p below. >>> p = re.compile(r"\[(?P<header>.*)\]")
>>> m = p.search("[Test[2]_foo]")
>>> m.group('header')
'Test[2]_foo' Additional note: Postel's principle was formulated for internet protocols, which .ini files are not. In any case, it is not a Python design principle. Neither is "always check user input", which amounts to 'look before you leap'. So I will not debate these. However, "Errors should never pass silently." is #10 on the Zen of Python ('import this') and that I do attend to. |
I agree with Terry, it's the opposite: we must explicitly reject them to be compatible with other applications. Please move the discussion to issue bpo-25723. |
Victor, I reopened this a a doc issue to add the sentence that would have cut short the discussion. Please leave it. |
Yes, the doc issue is separate from the other bug, since that one will apply only to 3.6, and the doc changes apply to all maintenance releases. |
The comment Terry suggests to add (see https://bugs.python.org/issue20923#msg255304) could be placed in this paragraph: https://docs.python.org/3/library/configparser.html#supported-ini-file-structure |
I am newbie to Python developer group and have the document source build and compiled successfully. Is this issue updated in the document. Thanks |
It’s still open. Go for it. |
Thanks. |
Thank you @Vidhya! |
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: