Issue549037
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2002-04-26 12:00 by lannert, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
cfgparser.patch | niemeyer, 2002-11-07 22:04 | Updated alternative implementation |
Messages (4) | |||
---|---|---|---|
msg39704 - (view) | Author: Detlef Lannert (lannert) | Date: 2002-04-26 12:00 | |
Each configuration file parsed by ConfigParser.py must start with a section header line (a section name enclosed in [...]). In many cases where I just want to parse a file with some variable settings for a program this is IMO a nuisance: The user must know the expected section name and insert a redundant header line, even if there are no other sections possible. The "surprise factor" is even higher when RFC[2]822 syntax is used; the config file then looks more like a standard mail header which wouldn't start with a section title anyway. Since the config file is read and the case of missing section titles handled in the __read() method of the ConfigParser, there is no easy way to modify the parser's behaviour just by subclassing and overwriting a method. The patch lets the caller specify a default section name; if the config file doesn't start with a [section] line but with option lines, a suitable section is automatically created and holds the option entries. In any other case, i.e., when the header line is present in the config file and/or when no default startsection name is specified, the parser's behaviour is unchanged. Thus there shouldn't be a compatibility issue. In case the upload of the patch file fails (which has happened to me and my browser before), please have a look at <http://starship.python.net/~lannert/ConfigParser.diff>; the diffs also add some lines to test_cfgparser.py. |
|||
msg39705 - (view) | Author: Gustavo Niemeyer (niemeyer) * | Date: 2002-11-07 21:15 | |
Logged In: YES user_id=7887 Thanks for purposing that Detlef. Having a configuration file without headers could indeed be interesting in some situations. I have a few comments about the implementation: The patch includes a new parameter in read functions, stating what's the first section name. It means that we could have other sections after the first unheaded section. IMO, that situation should still be considered an error. One possible way to implement it is to include a "noheaders" boolean parameter for the constructor. Then, the user would have to know what's the standard single section name, to pass it to functions like get(). Another way would be to include something like a "singlesection" parameter in the constructor. This parameter would accept a string option, which would name the single section. As an argument against the whole issue, I'm not sure how unconfortable it is to simply include a header in the file to satisfy the parser. As an argument favorable, this could allow ConfigParser to parse simple (no escapes or variables) shell configuration files and other simple configurations using NAME=VALUE style. I'm attaching an alternative implementation of the singlesection algorithm, described above. Would it be enough for your needs? |
|||
msg39706 - (view) | Author: Gustavo Niemeyer (niemeyer) * | Date: 2002-11-07 21:16 | |
Logged In: YES user_id=7887 Thanks for purposing that Detlef. Having a configuration file without headers could indeed be interesting in some situations. I have a few comments about the implementation: The patch includes a new parameter in read functions, stating what's the first section name. It means that we could have other sections after the first unheaded section. IMO, that situation should still be considered an error. One possible way to implement it is to include a "noheaders" boolean parameter for the constructor. Then, the user would have to know what's the standard single section name, to pass it to functions like get(). Another way would be to include something like a "singlesection" parameter in the constructor. This parameter would accept a string option, which would name the single section. As an argument against the whole issue, I'm not sure how unconfortable it is to simply include a header in the file to satisfy the parser. As an argument favorable, this could allow ConfigParser to parse simple (no escapes or variables) shell configuration files and other simple configurations using NAME=VALUE style. I'm attaching an alternative implementation of the singlesection algorithm, described above. Would it be enough for your needs? |
|||
msg39707 - (view) | Author: Gustavo Niemeyer (niemeyer) * | Date: 2002-11-08 13:33 | |
Logged In: YES user_id=7887 After a discussion in python-dev, it was decided that this function is not worth having in the ConfigParser standard class, since it's easy to include a dummy header in the file, and ConfigParser can also be subclassed. The complete discussion can be checked at: http://mail.python.org/pipermail/python-dev/2002-November/029968.html Thank you! |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:16 | admin | set | github: 36502 |
2002-04-26 12:00:30 | lannert | create |