Sorry, I didn't follow up here like I should have, and I haven't
followed the rest of this conversation, so apologies if I am being
redundant...
Fuzzyman wrote:
>>While ConfigParser is okay for simple configuration, it is (IMHO) not a
>>very good basis for anyone who wants to build better systems, like
>>config files that can be changed programmatically, or error messages
>>that point to file and line numbers. Those aren't necessarily features
>>we need to expose in the standard library, but it'd be nice if you could
>>implement that kind of feature without having to ignore the standard
>>library entirely.
>>
>>
>
> Can you elaborate on what kinds of programattic changes you envisage ?
> I'm just wondering if there are classes of usage not covered by
> ConfigObj. Of course you can pretty much do anything to a ConfigObj
> instance programattically, but even so...
ConfigObj does fine, my criticism was simply of ConfigParser in this
case. Just yesterday I was doing (with ConfigParser):
conf.save('app:main', '## Uncomment this next line to enable
authentication:\n#filter-with', 'openid')
This is clearly lame ;)
>>That said, I'm not particularly enthused about a highly featureful
>>config file *format* in the standard library, even if I would like a
>>much more robust implementation.
>>
>>
>
> I don't see how you can easily separate the format from the parser -
> unless you just leave raw values. (As I said in the other email, I don't
> think I fully understand you.)
>
> If accessing raw values suits your purposes, why not subclass
> ConfigParser and do magic in the get* methods ?
I guess I haven't really looked closely at the implementation of
ConfigParser, so I don't know how serious the subclassing would have to
be. But, for example, if you wanted to do nested sections this is not
infeasible with the current syntax, you just have to overload the
meaning of the section names. E.g., [foo.bar] (a section named
"foo.bar") could mean that this is a subsection of "foo". Or, if the
parser allows you to see the order of sections, you could use [[bar]] (a
section named "[bar]") to imply a subsection, not unlike what you have
already, except without the indentation.
I think there's lots of other kinds of things you can do with the INI
syntax as-is, but providing a different interface to it. If you allow
an easy-to-reuse parser, you can even check that syntax at read time.
(Or if you keep enough information, check the syntax later and still be
able to signal errors with filenames and line numbers)
An example of a parser that doesn't imply much of anything about the
object being produced is one that I wrote here:
http://svn.colorstudy.com/INITools/trunk/initools/iniparser.py
On top of that I was able to build some other fancy things without much
problem (which ended up being too fancy, but that's a different issue ;)
>> From my light reading on ConfigObj, it looks like it satisfies my
>>personal goals (though I haven't used it), but maybe has too many
>>features, like nested sections. And it seems like maybe the API can be
>>
>
> I personally think nested sections are very useful and would be sad to
> not see them included. Grouping additional configuration options as a
> sub-section can be *very* handy.
Using .'s in names can also do grouping, or section naming conventions.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
