> I like this, its really nice that it fits well with optparse. Thanks.
> I read through the docs, mostly it seems very logical, the following > things stood out to me as not really fitting: > > http://cfgparse.sourceforge.net/cfgparse-round-trip-set.html > It doesn't seem logical that in order to modify the option in the > desired section correctly, you need to pass the config file in. The keys > argument in the option itself should be able to determine this. There is a lot of necessary flexibility built into the interfaces for round trip and it sounds like it is tripping you up. The user may choose to split their configuration up into multiple files and use <include> to pull it all together. When you program your application you have a choice. Don't pass in a config file object and let it set the option where ever the user has it --OR-- pass in the configuration file object where you want it set and it won't matter where the user put it. BTW, since you may not know where the user put the setting, the set() method returns the config file object that was updated so that you may write its contents out. I just noticed this is undocumented and I will fix that in the next release. > http://cfgparse.sourceforge.net/node24.html > The use of <b> and <v> for quoting seems obscure. Would it not be better > to use pythonic triple-quoted strings? > On first glance they look like markup tags rather than multi-line > continuations (particularly <b> looks like "bold"). I did consider triple quotes but decided against it for the following reasons: 1) I couldn't think of a good way to distinguish between blocks and verbatim blocks without it being too subtle. 2) XML encapsulation may be more understandable to the majority of end users (of which many are not Python programmers). 3) XML offers a style that will be extensible for future additions. I'm not opposed to changing this area but it will need good a argument and consensus. > The fact that lines without an equals sign are ignored seems a bit > lenient ... Perhaps. If I get good arguments as to why it should be more stringent and a consensus is formed this could be changed. > It also seems strange how different the structure is between the > ini-style and the Python-style formats: > http://cfgparse.sourceforge.net/cfgparse-python.html > > driver = 'ethernet' > path = { 'DEFAULT' : '192.168.0.99', > 'DEV0' : '192.168.0.0', > 'DEV1' : '192.168.0.1' } > > Is equivalent to: > > [DEFAULT] > driver = 'ethernet' > path = 192.168.0.99 > [DEV0] > path = 192.168.0.0 > [DEV1] > path = 192.168.0.1 > > I wonder whether it would be better to use Python classes to represent > the same thing: > > class DEFAULT: > driver = 'ethernet' > path = '192.168.0.99' > > class DEV0(DEFAULT): > path = '192.168.0.0' > > class DEV1(DEFAULT): > path = '192.168.0.1' > > This seems to me to bear more logical structure resemblance to the > ini-style format. Classes cannot be used because they have a restricted character set. The INI style was implemented to be similar to what is already in the standard library and has the benefits of simplicity yet maitains a lot of flexibility. Because of this I'm anticipating it to be the style of choice by the vast majority. The Python style is for power users. I believe both styles lend themselves to visualizing how all the settings get blended together in a master dictionary. I'm open to tweaking the Python syntax if there are good arguments and concensus. > Otherwise really cool! Thanks again for your feedback. It is appreciated. I've spent a fair amount of time implementing and testing features that I don't really use in order to be able to contribute this to the Python community. If you would like to see it (or see specific features it has) in the standard library I encourage you to make comments at http://www.python.org/moin/ConfigParserShootout Regards, Dan Gass -- http://mail.python.org/mailman/listinfo/python-list
