[Python-Announce] cfgparse v01_00 released

[Dan Gass]

I'm pleased to announce the initial release of cfgparse (V01_00)

Background
-------------------------------------------------------------
cfgparse is a more convenient, flexible, and powerful module for
parsing configuration files than the standard library ConfigParser
module. cfgparse uses a more declarative style modelled after the
popular optparse standard library module.

cfgparse can optionally cooperate with the optparse module to provide
coordination between command line and configuration file options. In
addition, the cooperation can be used to allow the user to control
features of the parser from the command line.

URLs
-------------------------------------------------------------
Docs/home page: http://cfgparse.sourceforge.net/
Download: http://sourceforge.net/projects/cfgparse/

Feature Summary
-------------------------------------------------------------
+ Simple ini style configuration syntax
+ Type checking with error handling and help messages
+ Help summary modelled after that in optparse
+ Round trip - read, modify, write configuration files with comment retention
+ Cooperates with optparse for configuration file options that should be
overridden by command line options
+ Supports heirarchically organized option settings
* User may store multiple option settings in a arbitrarily deep
keyed dictionary.
* Application uses a key list to walk into the dictionary to
obtain a setting.
* User controls key list with setting in configuration file.
* Supports adding keys to the list through a command line option or from
environment variables.
+ Supports allowing user control of configuration files used.
* Environment variables may be used to allow user to specify a default
configuration file.
* Command line options to specify configuration file supported.
* Configuration files may include other configuration files where where
sections are read in parallel.
* Configuration files may be nested heirarchically by including
configuration
files from within a section or subsection.
+ Configuration files may alternatively be written in Python.
* full power and flexibility of Python available for creation of
option settings
* allows options settings to be real Python objects
* this feature is NOT enabled by default
+ May be extended to support syntax such as XML.

Enjoy,
Dan Gass

 

[David Fraser]

I'm pleased to announce the initial release of cfgparse (V01_00)

Background
-------------------------------------------------------------
cfgparse is a more convenient, flexible, and powerful module for
parsing configuration files than the standard library ConfigParser
module. cfgparse uses a more declarative style modelled after the
popular optparse standard library module.

cfgparse can optionally cooperate with the optparse module to provide
coordination between command line and configuration file options. In
addition, the cooperation can be used to allow the user to control
features of the parser from the command line.

I like this, its really nice that it fits well with optparse.
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.

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").

The fact that lines without an equals sign are ignored seems a bit
lenient ...

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.

Otherwise really cool!

David

 

[dan.gass]

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