ConfigParser - add a stop sentinel?

[rzed]

I am working with PythonCard in one of my apps. For its purposes, it
uses an .ini file that is passed to ConfigParser. For my app, I also
need configuration information, but for various reasons, I'd rather
use a syntax that ConfigParser can't handle.

I know I can maintain two separate configuration files, and if I have
to I will, but I'd rather avoid that, if possible, and a solution
that suits my purposes is quite straightforward . I insert a sentinel
in the ini file and modify my local ConfigParser's _read method to
stop accepting input when it encounters that value. I handle my app's
portion of the configuration myself.

This all works fine, but I was wondering whether it might be
worthwhile to add a standard stop flag in ConfigParser itself. Am I
the only one with this sort of use case? If there were a standard way
of doing this, I'd much rather use that, particularly if I ever have
reason to distribute the app elsewhere.
--
rzed

[Larry Bates]

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.

Regards,
Larry Bates

rzed wrote:

I am working with PythonCard in one of my apps. For its purposes, it
uses an .ini file that is passed to ConfigParser. For my app, I also
need configuration information, but for various reasons, I'd rather
use a syntax that ConfigParser can't handle.

I know I can maintain two separate configuration files, and if I have
to I will, but I'd rather avoid that, if possible, and a solution
that suits my purposes is quite straightforward . I insert a sentinel
in the ini file and modify my local ConfigParser's _read method to
stop accepting input when it encounters that value. I handle my app's
portion of the configuration myself.

This all works fine, but I was wondering whether it might be
worthwhile to add a standard stop flag in ConfigParser itself. Am I
the only one with this sort of use case? If there were a standard way
of doing this, I'd much rather use that, particularly if I ever have
reason to distribute the app elsewhere.

[rzed]

Larry Bates <lb****@syscono nline.com> wrote in
news:nZ******** ************@co mcast.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