cfgparse v01_00 released

[dan.gass at gmail.com]

> 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