ConfigParser - add a stop sentinel?

[rzed]

Larry Bates <lbates at syscononline.com> wrote in
news:nZqdnQYU7Z5O_XjcRVn-jA at comcast.com: 

[responding to the idea of placing a sentinel in an ini file, 
and modifying ConfigParser to stop receiving input when it is
encountered]:

> You should probably consider NOT doing what you suggest.  You
> would need to do some rather extensive work so you can support
> the .write method of ConfigParser.  With a little ingenuity
> I've been able to user ConfigParser to support some very
> different and complex syntaxes on different projects.  If this
> won't work, just have two different (separate) files.
> 
> If you are dead set on combining these two, put your foreign
> syntax lines into the file as comments.  ConfigParser will
> not process them, and you can have some other class extract
> only the comments and parse them independently.

I'm not sure I understand what you mean about the .write method of 
ConfigParser. I'm not trying to alter the *behavior* of 
ConfigParser at all, just giving it an alternative end of input 
(apart from EOF). And I'm not trying to replicate ConfigParser in 
my own configuration stuff. If I were, I'd just use ConfigParser. 

What I am doing is specifying a cluster of parameters on a single 
line in a compact, comma-separated form. I can easily split each 
parameter line and use the appropriate values, but it's not 
something ConfigParser is designed to accommodate, as far as I can 
tell.

I don't want to put them into comments (though I could, I see), 
because I comment my own lines with hashmarks as well. I suppose I 
could lead off with double hashmarks and just strip off the first 
to get the desired effect, but it's an annoyance and it doesn't 
contribute to understanding what the config file is supposed to do. 
Still, as a workaround, it is something to consider.

I just can't imagine that I'm the first person in history to have 
stumbled on such a use case, though. If ConfigParser would have a 
way to just take in raw data line-by-line within some group 
heading, that would work for this case just as well, and it seems 
to me that *that* might be useful in some other applications also 
... though that's not what I'm talking about in this instance.
 
-- 
rzed