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.

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? 
 

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? 
 

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!