469,275 Members | 1,601 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,275 developers. It's quick & easy.

ConfigParser - add a stop sentinel?

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

Jul 18 '05 #1
2 1483
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.

Jul 18 '05 #2
Larry Bates <lb****@syscononline.com> wrote in
news:nZ********************@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

Jul 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Greg Krohn | last post: by
1 post views Thread by Martin Maney | last post: by
2 posts views Thread by Roy H. Berger | last post: by
6 posts views Thread by Matthew Barnes | last post: by
11 posts views Thread by Manlio Perillo | last post: by
10 posts views Thread by Terry Carroll | last post: by
1 post views Thread by pipehappy | last post: by
4 posts views Thread by Phoe6 | last post: by
1 post views Thread by CARIGAR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.