configobj-develop — Support and development of ConfigObj

[Configobj-develop] round-tripping with ConfigObj

[Stewart M. <mi...@ya...>]

Hi Fuzzy, I have a question about round-tripping in ConfigObj, as per
the "product description".  

My expectation was that if I parse an input file with configobj and
then write back to the file with configobj, my comments would be
retained.  But it seems that they are not. 

>>> from configobj import ConfigObj
>>> text = open('pwadmin.ini').read()
>>> text
'#initial settings for pwadmin.py\npwProjectHome =
C:\\Programs\\PipeWorksB\\lib
\\python\\admin'
>>> attributes = ConfigObj('pwadmin.ini')
>>> attributes
{'pwProjectHome': 'C:\\Programs\\PipeWorksB\\lib\\python\\admin'}
>>> attributes.initial_comment
['#initial settings for pwadmin.py']
>>> config = ConfigObj(attributes)
>>> config.filename = 'pwadmin.out.ini'
>>> config.write()
>>> text = open('pwadmin.out.ini').read()
>>> text
'pwProjectHome = C:\\Programs\\PipeWorksB\\lib\\python\\admin'
>>>

It looks as though, if I want comments retained in my settings file,
I will have to manually write out initial comments, then section
comments (if any), then final comments.   Is that correct?   I don't
see this aspect explicitly addressed in the documentation. 

thanks
Stewart in Calgary


Stewart Midwinter
Please respond to st...@mi...
Visit http://midwinter.ca or http://midtoad.org

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Configobj-develop] Patch: problem with using is_list for is_string

[Fuzzyman <fuz...@vo...>]

Konrad Wojas wrote:

>Using is_list for is_string in validate.py is a bad idea, because if you
>specify that 'foo' is a string_list and you enter a string 'bar' into
>the config file instead of a list, you get the list ['b', 'a', 'r'] as
>value instead of an error.
>  
>
Thanks for this, it sounds like a sensible fix. I'll assess it in the
next couple of days.

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

>Kind regards,
>  
>
>------------------------------------------------------------------------
>

[Configobj-develop] Patch: problem with using is_list for is_string

[Konrad W. <th...@wo...>]

Using is_list for is_string in validate.py is a bad idea, because if you
specify that 'foo' is a string_list and you enter a string 'bar' into
the config file instead of a list, you get the list ['b', 'a', 'r'] as
value instead of an error.

Kind regards,
-- 
Konrad Wojas
The Health Agency BV
http://www.thehealthagency.com
th...@wo...

[Configobj-develop] Pythonutils API Documentation

[<fuz...@vo...>]

{ran_emo} Along with the new version of `ConfigObj <http://www.voidspace.org.uk/python/configobj.html>`_ are new auto-generated {acro;API;Application Programmers Interface} docs.

These can be found over at :

    `Pythonutils API Docs <http://www.voidspace.org.uk/python/configobj-api/>`_

These have been created with the `Epydoc 3.0 alpha <http://sourceforge.net/projects/epydoc>`_. As a result, they are *much* better looking (and hopefully useful) than their predecessor. Moving a lot of the tests out of the main module has helped with this.

[Configobj-develop] ConfigObj New Features

[<fuz...@vo...>]

{ran_emo} A new version of `ConfigObj <http://www.voidspace.org.uk/python/configobj.html>`_ is now available. As well as a few bugfixes (and the file size shrinking 40% due to the separation of the tests and changelog), there are several important new features.

Despite being relatively easy to code, these greatly extend the capabilities of **ConfigObj**. These extracts from the docs summarise what is new.

* *Empty Values* are now valid syntax, with a new option to write them
* *Copy Mode* allows the creation of default config files from a configspec, including comments
* *unrepr mode* allows for the storing and retrieving of basic Python datatypes

.. raw:: html

    {title;Empty values}

From `Empty Values <http://www.voidspace.org.uk/python/configobj.html#empty-values>`_.

Many config files from other applications allow empty values. As of version
4.3.0, ConfigObj will read these as an empty string.

A new option/attribute has been added (``write_empty_values``) to allow
ConfigObj to write empty strings as empty values.

.. raw:: html

    {+coloring}
    from configobj import ConfigObj
    cfg = '''
        key =
        key2 = # a comment
    '''.splitlines()
    config = ConfigObj(cfg)
    print config
    {'key': '', 'key2': ''}
    
    config.write_empty_values = True
    for line in config.write():
        print line
    
    key = 
    key2 =     # a comment
    {-coloring}


.. raw:: html

    {title;Copy Mode}

From `Copy Mode <http://www.voidspace.org.uk/python/configobj.html#copy-mode>`_.

Because you can specify default values in your configspec, you can use
ConfigObj to write out default config files for your application.

However, normally values supplied from a default in a configspec are *not*
written out by the ``write`` method.

To do this, you need to specify ``copy=True`` when you call validate. As well
as not marking values as default, all the comments in the configspec file
will be copied into your ConfigObj instance.

.. raw:: html

    {+coloring}
    from configobj import ConfigObj
    from validate import Validator
    vdt = Validator()
    config = ConfigObj(configspec='default.ini')
    config.filename = 'new_default.ini'
    config.validate(vdt, copy=True)
    config.write()
    {-coloring}

.. hint::

   There are functions to assist in the *automatic* creation of a configspec, in the `ConfigPersist Module <http://www.voidspace.org.uk/python/configpersist.html>`_.

.. raw:: html

    {title;unrepr mode}

From `unrepr mode <http://www.voidspace.org.uk/python/configobj.html#unrepr-mode>`_.

The ``unrepr`` option allows you to store and retrieve the basic Python
data-types using config files. It has to use a slightly different syntax to
normal ConfigObj files. Unsurprisingly it uses Python syntax.

This means that lists are different (they are surrounded by square brackets),
and strings *must* be quoted.

The types that ``unrepr`` can work with are :

    | strings, lists tuples
    | None, True, False
    | dictionaries, integers, floats
    | longs and complex numbers
    
You can't store classes, types or instances.

``unrepr`` uses ``repr(object)`` to write out values, so it currently *doesn't*
check that you are writing valid objects. If you attempt to read an unsupported
value, ConfigObj will raise a ``configobj.UnknownType`` exception.

Values that are triple quoted cased. The triple quotes are removed *before*
converting. This means that you can use triple quotes to write dictionaries
over several lines in your config files. They won't be written like this
though.

If you are writing config files by hand, for use with ``unrepr``, you should
be aware of the following differences from normal ConfigObj syntax :

    | List : ``['A List', 'With', 'Strings']``
    | Strings : ``"Must be quoted."``
    | Backslash : ``"The backslash must be escaped \\"``

These all follow normal Python syntax.

So **ConfigObj** can now be used for simple (as in easy) data persistence. Move over `YAML <http://pyyaml.org/wiki/PySyck>`_. {sm;:wink:}

[Configobj-develop] ConfigObj 4.3.0

[<fuz...@vo...>]

{ran_emo} `ConfigObj 4.3.0 <http://www.voidspace.org.uk/python/configobj.html>`_ is now released.

This has several bugfixes, as well as *several* major feature enhancements.

You can download it from :

   `ConfigObj-4.3.0.zip 244Kb <http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj-4.3.0.zip>`_

.. raw:: html

    {title;What is ConfigObj ?}

**ConfigObj** is a simple but powerful config file reader and writer: an *ini
file round tripper*. Its main feature is that it is very easy to use, with a
straightforward programmer's interface and a simple syntax for config files.
It has lots of other features though :

* Nested sections (subsections), to any level
* List values
* Multiple line values
* String interpolation (substitution)
* Integrated with a powerful validation system

    - including automatic type checking/conversion
    - repeated sections
    - and allowing default values

* All comments in the file are preserved
* The order of keys/sections is preserved
* No external dependencies
* Full Unicode support
* A powerful ``unrepr`` mode for storing basic datatypes

.. raw:: html

    {title;What's New ?}

Moved the tests and the CHANGELOG (etc) into a separate file. This has reduced the size of ``configobj.py`` by about 40%.

Added the ``unrepr`` mode to reading and writing config files. Thanks to Kevin Dangoor for this suggestion.

Empty values are now valid syntax. They are read as an empty string ``''``.
(``key =``, or ``key = # comment``.)

``validate`` now honours the order of the configspec.

Added the ``copy`` mode to validate. Thanks to Louis Cordier for this
suggestion.

Fixed bug where files written on windows could be given ``'\r\r\n'`` line
terminators.

Fixed bug where last occurring comment line could be interpreted as the
final comment if the last line isn't terminated.

Fixed bug where nested list values would be flattened when ``write`` is
called. Now sub-lists have a string representation written instead.

Deprecated ``encode`` and ``decode`` methods instead.

You can now pass in a ConfigObj instance as a configspec (remember to read
the configspec file using ``list_values=False``).

[Configobj-develop] ConfigObj Tests

[Fuzzyman <fuz...@vo...>]

Hello all,

I've split the ConfigObj tests into a separate file, and the 
changelog/todo etc into a text file.

There are some example tests left in configobj.py.

This has brought configobj.py down from 3700 lines to 2100 lines. (123k 
to 74k)

I'll upload these to SVN tonight (4.3.0alpha4). Once I've done the doc 
changes, which are quite extensive, I'll do the release. This might take 
another week or so.

Currently the copy mode of validate *doesn't* handle the 'DEFAULT' 
sections. validate doesn't touch them so that you *can* use string 
interpolation in your configspec files. I can't think of a clean way 
round this, so I'm not proposing to fix it for the moment. If this 
causes anyone problems I/we will have to find the best way round it. 
Maybe validation could just copy any DEFAULT sections without passing 
them through any validator checks ?

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Configobj-develop] ConfigObj Tests

[Fuzzyman <fuz...@vo...>]

Nicola Larosa wrote:
>> Seeing as I'm going to do a new release of ConfigObj I might as well
>> move the tests into a separate file.
>>     
>
> Yes, sorry for not having got round to doing it myself, as promised. :-(
>
>   

Not a problem, it's an easy job.
>   
>> For the sake of consistency I suppose I have to move *all* the tests.
>>     
>
> Not necessarily.
>   
I'm copying *all* the tests into a file called ``configobj_test.py``. 
I'm leaving a few useful ones in configobj.py as well.

>> If there are any that serve as particularly concise examples I might
>> leave them in place, but the tests have grown quite unwieldy now.
>>     
>
> Indeed, one or two tests could be usefully left in each docstring as usage
> examples.
>
>
>   

There won't be any doctest stuff in configobj.py, so they are now 
examples only.
>> Removing the tests and some of the text will shrink configobj.py by
>> quite a way.
>>     
>
> Definitely.

I've removed some of the text. I've left the ISSUES and CHANGELOG in as 
it is useful to keep these *in* the file. That way someone who just has 
configobj.py still has some information about it.

I suppose the CHANGELOG doesn't contain that much information, so I 
wouldn't be averse to moving that into a separate text file if you 
thought it was better. (About 400 odd lines.)

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Configobj-develop] ConfigObj Tests

[Nicola L. <ni...@te...>]

> Seeing as I'm going to do a new release of ConfigObj I might as well
> move the tests into a separate file.

Yes, sorry for not having got round to doing it myself, as promised. :-(


> For the sake of consistency I suppose I have to move *all* the tests.

Not necessarily.


> If there are any that serve as particularly concise examples I might
> leave them in place, but the tests have grown quite unwieldy now.

Indeed, one or two tests could be usefully left in each docstring as usage
examples.


> Removing the tests and some of the text will shrink configobj.py by
> quite a way.

Definitely.

-- 
Nicola Larosa - http://www.tekNico.net/

I have not heard of any of the rather significant core of Python language
and library developers saying "hey, this Ruby thing really solves a lot
of problems we've been having in Python, I'm going over there." Instead,
they write PEPs (Python Enhancement Proposals) and morph the language to
incorporate the good features. -- Bruce Eckel, December 2005

[Configobj-develop] ConfigObj Tests

[Fuzzyman <fuz...@vo...>]

Hello,

Seeing as I'm going to do a new release of ConfigObj I might as well 
move the tests into a separate file.

For the sake of consistency I suppose I have to move *all* the tests. If 
there are any that serve as particularly concise examples I might leave 
them in place, but the tests have grown quite unwieldy now.

Removing the tests and some of the text will shrink configobj.py by 
quite a way.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Configobj-develop] ConfigObj 4.3.0alpha

[Michael F. <fuz...@vo...>]

Michael Foord wrote:
> Hmmm.... I'm now being bitten by all the ``isinstance(value, dict)`` 
> checks in ConfigObj.
>
> When you unrepr a dictionary (or set a value as a dictionary) 
> ConfigObj creates a new section.
>
> I'll have to create a new keyword argument for 
> ``Section.__setitem__``, ``unrepr``. If this is True then setting a 
> dictionary won't create a new section.
>
> This makes unrepr incompatible with validate, but I guess this is 
> inevitable. It also means that to set a dictionary in unrepr mode you 
> have to do :
>
>    cfg.__setitem__(key, value, unrepr=True)
>
> I'll have to check where else this might bite - probably walk as well.
>
There is now a fix in alpha 3 (in SVN). You can now read in a dictionary 
in ``unrepr`` mode.

To set a value as a dictionary, without creating a new section, use the 
idiom :

    cfg = ConfigObj(filename)
    cfg.__setitem__(key, value, unrepr=True)

Where value is a dictionary. I couldn't *see* any cases where this would 
cause problems, except possibly using ``merge`` from one ConfigObj to 
another. I'll put a warning about this in the docs. ``validate`` goes 
over the sections separately, without using ``isinstance`` checks on 
values, so it should work fine, except that validators must be prepared 
for a wider range of types than they would otherwise see.

``unrepr`` mode should be used with care though. :-)

It actually extends the abilities of ConfigObj a great deal, enabling 
you to store basic Python datatypes in a ConfigObj file. These can 
remain readable if you store them as multiline values. (Because it uses 
``repr``, the ``write`` method won't write them as multiline values.) 
Move over YAML. ;-)

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Fuzzyman
> http://www.voidspace.org.uk/python/index.shtml
>
> fuz...@vo... wrote:
>>
>>
>>     ConfigObj 4.3.0alpha
>>
>> emoticon:ir_scope The Pythonutils SVN Repository 
>> <http://svn.pythonutils.python-hosting.com/trunk/pythonutils/> now 
>> contains an alpha version of ConfigObj 
>> <http://www.voidspace.org.uk/python/configobj.html>. This will become 
>> *ConfigObj 4.3.0*.
>>
>> I hadn't intended to move so quickly from 4.2.0 to 4.3.0, but some 
>> interesting discussions on the configobj-develop list 
>> <http://sourceforge.net/mail/?group_id=123265> have led to some 
>> fairly major feature enhancements.
>>
>> These are all implemented and tested, but they do raise a couple of 
>> issues and as usual I'd like to see people kicking the code before I 
>> do a new release.
>>
>> The new features include :
>>
>>     * Support for a copy mode in validation, allowing you to create a
>>       default config file /with comments/ from your configspec.
>>     * Support for reading empty values (key = and key = # comment) as
>>       an empty string.
>>     * A new write_empty_values option/attribute that will write the
>>       empty string as empty values.
>>     * A new unrepr mode. Explained below.
>>
>> I have also discovered and fixed three bugs [1] <#e275id4> :
>>
>>     * Line terminators were incorrectly written on windoze. Embarassed
>>     * Last occurring comment line could be interpreted as the final
>>       comment if the last line wasn't terminated.
>>     * Nested list values would be flattened when write was called. Now
>>       sub-lists have a string representation written instead.
>>
>> Finally the encode and decode methods have been deprecated. I 
>> /didn't/ deprecate rename as it should be used with walk to transform 
>> key and section names. encode and decode are still good examples of 
>> this by the way. [2] <#e275id5>
>>
>>
>>       copy mode for validate
>>
>> Thanks to /Louis Cordier/ for this suggestion. When you supply a 
>> configspec you can specify default values to use for any that are 
>> missing from the config file.
>>
>> Normally when you call the validate method 
>> <http://www.voidspace.org.uk/python/configobj.html#validate> it marks 
>> any missing values as having been supplied from the default. If you 
>> then call write it /doesn't/ write out any values supplied from 
>> defaults (unless you change them). This allows you to keep a config 
>> file with /only/ values that are different from the defaults.
>>
>> The validate method now takes an optional copy keyword argument. If 
>> this is True, then none of the values are marked as default. In 
>> addition all the comments are copied across from the configspec, as 
>> are the indentation and encoding settings.
>>
>> A call to write will then write out a new config file with all the 
>> default values specified in the configspec. Smile
>>
>> This does however lead to me realise that there is currently no way 
>> to specify the encoding of a configspec file. Confused
>>
>> Update
>>
>> ConfigObj 4.3.0 alpha 2 now allows you to pass in a ConfigObj 
>> instance as your configspec. This is not a total solution, but does 
>> allow you to read the configspec using ConfigObj, and specify the 
>> encoding when you do that.
>>
>> In order to read a configspec file, you /must/ use the option 
>> list_values=False.
>>
>>
>>       unrepr mode
>>
>> This was suggested by /Kevin Dangoor/ the lead developer of 
>> Turbogears <http://www.turbogears.org/> [3] <#e275id6>. It mimics the 
>> unrepr mode of the CherryPy Config Module 
>> <http://www.cherrypy.org/wiki/ConfigSystem21>, and in fact uses the 
>> code from cptools.py 
>> <http://www.cherrypy.org/file/trunk/cherrypy/lib/cptools.py>.
>>
>> If you pass in the unrepr=True keyword when you create your ConfigObj 
>> instance, every value is parsed using unrepr. This allows you to have 
>> the following types as values :
>>
>>     integers, strings, True, False, None, floats, complex numbers,
>>     lists, dictionaries, tuples
>>
>> You /can/ use multiline values with unrepr. Smile
>>
>> When writing in unrepr mode, the built in function repr is used to 
>> turn every value into a string.
>>
>> Note that in unrepr mode :
>>
>>     /The value 3.0 is a float/
>>     /The value "3.0" is a string/
>>
>> Quote marks take on the same significance as they have in Python 
>> syntax, which is different from normal ConfigObj syntax.
>>
>> [1] <#e275id1>     But no longer useful since full unicode support 
>> was added.
>>
>> [2] <#e275id2>     validate also now honours the /order/ of your 
>> configspec. Before copy mode, this didn't really matter though.
>>
>> [3] <#e275id3>     Looks like ConfigObj won't be used in Turbogears 
>> until version 1.1 when a lot of things change.
>>
>> Posted by *Fuzzyman* on 2006-03-20 12:48:44.
>> Categories: Projects 
>> <http://www.voidspace.org.uk/python/weblog/arch_Projects.shtml>, 
>> Python <http://www.voidspace.org.uk/python/weblog/arch_Python.shtml>
>> Visit the Voidspace Techie Blog 
>> <http://www.voidspace.org.uk/python/weblog/index.shtml> to read this 
>> entry and more.
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

Re: [Configobj-develop] ConfigObj 4.3.0alpha

[Michael F. <fuz...@vo...>]

Hmmm.... I'm now being bitten by all the ``isinstance(value, dict)`` 
checks in ConfigObj.

When you unrepr a dictionary (or set a value as a dictionary) ConfigObj 
creates a new section.

I'll have to create a new keyword argument for ``Section.__setitem__``, 
``unrepr``. If this is True then setting a dictionary won't create a new 
section.

This makes unrepr incompatible with validate, but I guess this is 
inevitable. It also means that to set a dictionary in unrepr mode you 
have to do :

    cfg.__setitem__(key, value, unrepr=True)

I'll have to check where else this might bite - probably walk as well.

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

fuz...@vo... wrote:
>
>
>     ConfigObj 4.3.0alpha
>
> emoticon:ir_scope The Pythonutils SVN Repository 
> <http://svn.pythonutils.python-hosting.com/trunk/pythonutils/> now 
> contains an alpha version of ConfigObj 
> <http://www.voidspace.org.uk/python/configobj.html>. This will become 
> *ConfigObj 4.3.0*.
>
> I hadn't intended to move so quickly from 4.2.0 to 4.3.0, but some 
> interesting discussions on the configobj-develop list 
> <http://sourceforge.net/mail/?group_id=123265> have led to some fairly 
> major feature enhancements.
>
> These are all implemented and tested, but they do raise a couple of 
> issues and as usual I'd like to see people kicking the code before I 
> do a new release.
>
> The new features include :
>
>     * Support for a copy mode in validation, allowing you to create a
>       default config file /with comments/ from your configspec.
>     * Support for reading empty values (key = and key = # comment) as
>       an empty string.
>     * A new write_empty_values option/attribute that will write the
>       empty string as empty values.
>     * A new unrepr mode. Explained below.
>
> I have also discovered and fixed three bugs [1] <#e275id4> :
>
>     * Line terminators were incorrectly written on windoze. Embarassed
>     * Last occurring comment line could be interpreted as the final
>       comment if the last line wasn't terminated.
>     * Nested list values would be flattened when write was called. Now
>       sub-lists have a string representation written instead.
>
> Finally the encode and decode methods have been deprecated. I /didn't/ 
> deprecate rename as it should be used with walk to transform key and 
> section names. encode and decode are still good examples of this by 
> the way. [2] <#e275id5>
>
>
>       copy mode for validate
>
> Thanks to /Louis Cordier/ for this suggestion. When you supply a 
> configspec you can specify default values to use for any that are 
> missing from the config file.
>
> Normally when you call the validate method 
> <http://www.voidspace.org.uk/python/configobj.html#validate> it marks 
> any missing values as having been supplied from the default. If you 
> then call write it /doesn't/ write out any values supplied from 
> defaults (unless you change them). This allows you to keep a config 
> file with /only/ values that are different from the defaults.
>
> The validate method now takes an optional copy keyword argument. If 
> this is True, then none of the values are marked as default. In 
> addition all the comments are copied across from the configspec, as 
> are the indentation and encoding settings.
>
> A call to write will then write out a new config file with all the 
> default values specified in the configspec. Smile
>
> This does however lead to me realise that there is currently no way to 
> specify the encoding of a configspec file. Confused
>
> Update
>
> ConfigObj 4.3.0 alpha 2 now allows you to pass in a ConfigObj instance 
> as your configspec. This is not a total solution, but does allow you 
> to read the configspec using ConfigObj, and specify the encoding when 
> you do that.
>
> In order to read a configspec file, you /must/ use the option 
> list_values=False.
>
>
>       unrepr mode
>
> This was suggested by /Kevin Dangoor/ the lead developer of Turbogears 
> <http://www.turbogears.org/> [3] <#e275id6>. It mimics the unrepr mode 
> of the CherryPy Config Module 
> <http://www.cherrypy.org/wiki/ConfigSystem21>, and in fact uses the 
> code from cptools.py 
> <http://www.cherrypy.org/file/trunk/cherrypy/lib/cptools.py>.
>
> If you pass in the unrepr=True keyword when you create your ConfigObj 
> instance, every value is parsed using unrepr. This allows you to have 
> the following types as values :
>
>     integers, strings, True, False, None, floats, complex numbers,
>     lists, dictionaries, tuples
>
> You /can/ use multiline values with unrepr. Smile
>
> When writing in unrepr mode, the built in function repr is used to 
> turn every value into a string.
>
> Note that in unrepr mode :
>
>     /The value 3.0 is a float/
>     /The value "3.0" is a string/
>
> Quote marks take on the same significance as they have in Python 
> syntax, which is different from normal ConfigObj syntax.
>
> [1] <#e275id1> 	But no longer useful since full unicode support was 
> added.
>
> [2] <#e275id2> 	validate also now honours the /order/ of your 
> configspec. Before copy mode, this didn't really matter though.
>
> [3] <#e275id3> 	Looks like ConfigObj won't be used in Turbogears until 
> version 1.1 when a lot of things change.
>
> Posted by *Fuzzyman* on 2006-03-20 12:48:44.
> Categories: Projects 
> <http://www.voidspace.org.uk/python/weblog/arch_Projects.shtml>, 
> Python <http://www.voidspace.org.uk/python/weblog/arch_Python.shtml>
> Visit the Voidspace Techie Blog 
> <http://www.voidspace.org.uk/python/weblog/index.shtml> to read this 
> entry and more.
>

[Configobj-develop] ConfigObj 4.3.0alpha

[<fuz...@vo...>]

{emo;ir_scope} The `Pythonutils SVN Repository <http://svn.pythonutils.python-hosting.com/trunk/pythonutils/>`_ now contains an alpha version of `ConfigObj <http://www.voidspace.org.uk/python/configobj.html>`_. This will become **ConfigObj 4.3.0**.

I hadn't intended to move so quickly from 4.2.0 to 4.3.0, but some interesting discussions on the `configobj-develop list <http://sourceforge.net/mail/?group_id=123265>`_ have led to some fairly major feature enhancements.

These are all implemented and tested, but they do raise a couple of issues and as usual I'd like to see people kicking the code before I do a new release.

The new features include :

* Support for a ``copy`` mode in validation, allowing you to create a default config file *with comments* from your configspec.
* Support for reading empty values (``key =`` and ``key = # comment``) as an empty string.
* A new ``write_empty_values`` option/attribute that will write the empty string as empty values.
* A new ``unrepr`` mode. Explained below.

I have also discovered and fixed three bugs [#]_ :

* Line terminators were incorrectly written on windoze. {sm;:oops:}
* Last occurring comment line could be interpreted as the final comment if the last line wasn't terminated.
* Nested list values would be flattened when ``write`` was called. Now sub-lists have a string representation written instead.

Finally the ``encode`` and ``decode`` methods have been deprecated. I *didn't* deprecate ``rename`` as it should be used with ``walk`` to transform key and section names. ``encode`` and ``decode`` are still good examples of this by the way. [#]_

.. raw:: html

    {title;copy mode for validate}

Thanks to *Louis Cordier* for this suggestion. When you supply a configspec you can specify default values to use for any that are missing from the config file.

Normally when you call the `validate method <http://www.voidspace.org.uk/python/configobj.html#validate>`_ it marks any missing values as having been supplied from the default. If you then call ``write`` it *doesn't* write out any values supplied from defaults (unless you change them). This allows you to keep a config file with *only* values that are different from the defaults.

The ``validate`` method now takes an optional ``copy`` keyword argument. If this is ``True``, then none of the values are marked as default. In addition all the comments are copied across from the configspec, as are the indentation and encoding settings.

A call to ``write`` will then write out a new config file with all the default values specified in the configspec. {sm;:-)}

This does however lead to me realise that there is currently no way to specify the encoding of a configspec file. {sm;:???:}

.. admonition:: Update

    ConfigObj 4.3.0 alpha 2 now allows you to pass in a ConfigObj instance as your configspec. This is not a total solution, but does allow you to read the configspec using ConfigObj, and specify the encoding when you do that.

    In order to read a configspec file, you *must* use the option ``list_values=False``.


.. raw:: html

    {title;unrepr mode}

This was suggested by *Kevin Dangoor* the lead developer of `Turbogears <http://www.turbogears.org/>`_ [#]_. It mimics the ``unrepr`` mode of the `CherryPy Config Module <http://www.cherrypy.org/wiki/ConfigSystem21>`_, and in fact uses the code from `cptools.py <http://www.cherrypy.org/file/trunk/cherrypy/lib/cptools.py>`_.

If you pass in the ``unrepr=True`` keyword when you create your ConfigObj instance, every value is parsed using ``unrepr``. This allows you to have the following types as values :

    integers, strings, True, False, None, floats, complex numbers, lists, dictionaries, tuples

You *can* use multiline values with ``unrepr``. {sm;:-)}

When writing in unrepr mode, the built in function ``repr`` is used to turn every value into a string.

Note that in ``unrepr`` mode :

   | *The value 3.0 is a float*
   | *The value "3.0" is a string*

Quote marks take on the same significance as they have in Python syntax, which is different from normal ConfigObj syntax.

.. [#] But no longer useful since full unicode support was added.
.. [#] ``validate`` also now honours the *order* of your configspec. Before copy mode, this didn't really matter though.
.. [#] Looks like ConfigObj won't be used in Turbogears until version 1.1 when a lot of things change.

Re: [Configobj-develop] Re: unrepr

[Fuzzyman <fuz...@vo...>]

Kevin Dangoor wrote:
> On 3/17/06, Michael Foord <fuz...@gm...> wrote:
>   
>>> foo="bar"
>>> baz=True
>>> blork=8
>>>       
>
> [snip]
>   
>> I can add an 'unrepr' mode as an optional keyword (default False) that
>> implements it.
>>     
>
> You know what might be interesting: the ability to provide a callback
> to set each value. That would allow plugging in of different sorts of
> unrepr-style behavior.
>   
Hmm... sounds a little bit heavyweight for a config file reader/writer.

You can actually already do this by reading the config file in with 
``list_values`` set to ``False``. (This stops the parsing of values - 
except to remove any comment and handle multi line values I think). You 
then use the ``walk`` method and pass in a callable which is called on 
every value and each value is substituted with the return. Properly 
handling lists would be a pain this way - you would want to leverage the 
code already in ConfigObj to do this.

This however this isn't symmetric with ``write`` which *currently* won't 
quote a value if it doesn't need it - so a string value of  '1' will be 
written without quotes.
> Of course, there would have to be a companion function for handling
> the writing side of things as well.
>   
Do you envisage needing programmatic writing from Turbogears ? If not, 
ConfigObj can possibly already do what you want.

I'm happy to implement ``unrepr`` mode *anyway*.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
> Kevin
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>   

[Configobj-develop] Re: unrepr

[Kevin D. <da...@gm...>]

On 3/17/06, Michael Foord <fuz...@gm...> wrote:
> > foo=3D"bar"
> > baz=3DTrue
> > blork=3D8
>

[snip]

>
> I can add an 'unrepr' mode as an optional keyword (default False) that
> implements it.

You know what might be interesting: the ability to provide a callback
to set each value. That would allow plugging in of different sorts of
unrepr-style behavior.

Of course, there would have to be a companion function for handling
the writing side of things as well.

Kevin

[Configobj-develop] Re: unrepr

[Kevin D. <da...@gm...>]

On 3/17/06, Michael Foord <fuz...@gm...> wrote:
> I can't just make this change because it's not backward compatible.
>
> I can add an 'unrepr' mode as an optional keyword (default False) that
> implements it.

Yes, this is what I was thinking.

> Currently ConfigObj doesn't keep a record of whether a value was quoted o=
r
> not, so it would take a bit of work to add this into the parsing code (an=
d
> the writing code). Not too difficult though.

If the unrepr mode is being used, the writing code should be able to
just use repr(). Parsing would be different, though...

> The code from CherryPy will probably be helpful to see how it detects
> 'convertible values'.

Yep. And that code is freely usable, as well.

Kevin

[Configobj-develop] Re: unrepr

[Michael F. <fuz...@gm...>]

On 17/03/06, Kevin Dangoor <da...@gm...> wrote:
>
> Hi Michael,
>
> I ended up discovering that the path of least resistance for
> TurboGears 0.9a2 configuration was to use CherryPy''s config module. I
> still see a decent possibility, though, that I'm going to need to
> migrate to ConfigObj for TurboGears 1.1 (First Class).
>
> In order to either maintain backward compatibility with existing
> config files *or* to make the transition in an automated manner, I'd
> need ConfigObj to support CherryPy's "unrepr" format. It's actually a
> handy format in some ways, anyhow, because it gets you a bit of type
> conversion without a configspec. (A configspec will never fly with
> TurboGears, because the configuration options are determined by
> individual applications are parts that TurboGears brings together...)
>
> I have *no idea* if there's a mechanism in ConfigObj that would allow
> me to do the unrepr, or if a change is required in ConfigObj itself to
> do so. Here's what the config looks like:
>
> foo=3D"bar"
> baz=3DTrue
> blork=3D8


It's not currently possible. You can use the ``as_bool`` and ``as_int``
method to fetch values as integers etc.

Is it just ints and booleans that are automatically converted ? What about
floats ?

I can't just make this change because it's not backward compatible.

I can add an 'unrepr' mode as an optional keyword (default False) that
implements it.

Currently ConfigObj doesn't keep a record of whether a value was quoted or
not, so it would take a bit of work to add this into the parsing code (and
the writing code). Not too difficult though.

The code from CherryPy will probably be helpful to see how it detects
'convertible values'.

All the best,


Fuzzyman
http://www.voidspace.org.uk/python/index.shtml


> So, foo is a string, baz is a boolean and blork is an int. Quite
> simple, I think. The only drawback is that the user doing the config
> needs to use "" around strings.
>
> The unrepr that CherryPy uses is found here:
> http://svn.cherrypy.org/trunk/cherrypy/lib/cptools.py
>
> Thoughts?
>
> Kevin
>
> --
> Kevin Dangoor
> Author of the Zesty News RSS newsreader
>
> email: ki...@bl...
> company: http://www.BlazingThings.com
> blog: http://www.BlueSkyOnMars.com
>



--
http://www.Voidspace.org.uk
The Place where headspace meets cyberspace. Online resource site - covering
science, technology, computing, cyberpunk, psychology, spirituality, fictio=
n
and more.

---
http://www.Voidspace.org.uk/python/index.shtml
Python utilities, modules and apps.
Including Nanagram, Dirwatcher and more.
---
http://www.fuchsiashockz.co.uk
http://groups.yahoo.com/group/void-shockz
---

Everyone has talent. What is rare is the courage to follow talent
to the dark place where it leads. -Erica Jong
Ambition is a poor excuse for not having sense enough to be lazy.
         -Milan Kundera

Re: [Configobj-develop] Re: ConfigObj: Default config file, functionality.

[Fuzzyman <fuz...@vo...>]

Louis Cordier wrote:
> [snip..]
>
> Here is an example where walk() doesn't honour my configspec's order.
> For my needed end result, I don't really need walk() to do it in
> order thought.
>
>>>> configspec = '''
> ... [test]
> ...     c = string(default='c')
> ...     b = string(default='b')
> ...     a = string(default='a')
> ...     z = string(default='z')
> ... '''
>
>>>> c = ConfigObj(options={'configspec': configspec.split('\n')})
>>>> from validate import Validator
>>>> validator = Validator()
>>>> c.validate(validator)
> True
>>>> c
> {'test': {'a': 'a', 'c': 'c', 'b': 'b', 'z': 'z'}}
Note that here the order is *already* incorrect. So validate doesn't 
honour the order of the configspec. This is because the configspec is 
stored in a dictionary attached to the section - looks like I need to 
*also* store the order. I don't think I'll make that a public attribute 
though.

As far as I can tell from the code, ``walk`` *ought* to honour the 
order. I think this is why you are seeing it sometimes honour and 
sometimes not.

Fuzzyman
http://www.voidspace.org.uk/python/configobj.html

Re: [Configobj-develop] Re: ConfigObj: Default config file, functionality.

[Fuzzyman <fuz...@vo...>]

Louis Cordier wrote:
>
> On Fri, 17 Mar 2006, Fuzzyman wrote:
>> Can you explain to me what this actually does (sorry for my ignorance).
>>
>> You want to create a default config file from a configspec. You want 
>> to copy the comments from the configspec *into* the config file when 
>> this is done ?
>
> Yes, retaining the layout of the configspec.
>
>> You have attempted to do this with walk, but walk *doesn't* honour 
>> the order of the configspec, so you have implemented an alternative.
>
> My main aim wasn't to re-implement walk. In some case I have seen
> walk honour the order and in others not. (not too sure why)
>
Right - I think that where ``walk`` doesn't honour order that is a bug 
and I will fix it. Thanks for your example illustrating this.

> I simply tried to cheat write() into writing a config-file that the
> validator populated with default values. I used walk to recursively
> empty each section's defaults member (section.defaults = []).
> I noticed that write didn't write those entries that was in .defaults
> so I removed them all. ;)
>
Ahh... I forgot that normally ``write`` doesn't write out unchanged 
default values.

Instead of a ``copy_comments`` option we need a copy mode. How about an 
optional ``copy`` keyword to ``validate`` ? If this is set then comments 
are copied and none of the values supplied from the configspec are 
marked as default - in this case ``write`` should behave as expected.

> [snip..]
All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Configobj-develop] Re: ConfigObj: Default config file, functionality.

[Nicola L. <ni...@te...>]

> Nicola (other users/developers), are you happy for this to be built into
> ConfigObj, or would it be better as a separate function ?

No objections to having it built-in.

-- 
Nicola Larosa - http://www.tekNico.net/

One of the basic tenets of the Python language has been that code should
be simple and clear to express and to read, and Ruby has followed this
idea, although not as far as Python has because of the inherited Perlisms.
 -- Bruce Eckel, December 2005

[Configobj-develop] Re: ConfigObj: Default config file, functionality.

[Louis C. <lco...@po...>]

On Fri, 17 Mar 2006, Fuzzyman wrote:
> Can you explain to me what this actually does (sorry for my ignorance).
>
> You want to create a default config file from a configspec. You want to copy 
> the comments from the configspec *into* the config file when this is done ?

Yes, retaining the layout of the configspec.

> You have attempted to do this with walk, but walk *doesn't* honour the order 
> of the configspec, so you have implemented an alternative.

My main aim wasn't to re-implement walk. In some case I have seen
walk honour the order and in others not. (not too sure why)

I simply tried to cheat write() into writing a config-file that the
validator populated with default values. I used walk to recursively
empty each section's defaults member (section.defaults = []).
I noticed that write didn't write those entries that was in .defaults
so I removed them all. ;)

Here is an example where walk() doesn't honour my configspec's order.
For my needed end result, I don't really need walk() to do it in
order thought.

>>> configspec = '''
... [test]
...     c = string(default='c')
...     b = string(default='b')
...     a = string(default='a')
...     z = string(default='z')
... '''

>>> c = ConfigObj(options={'configspec': configspec.split('\n')})
>>> from validate import Validator
>>> validator = Validator()
>>> c.validate(validator)
True
>>> c
{'test': {'a': 'a', 'c': 'c', 'b': 'b', 'z': 'z'}}

>>> def p(s, k):
...     print s.name, k
...

#
# The order is incorrect.
#

>>> c.walk(p)
test a
test c
test b
test z
{'test': {'a': None, 'c': None, 'b': None, 'z': None}}

However, if I were to use walk() to create a new ConfigObj() and
write that to file, it will write the entries in the file in the
order they we added to the config ConfigObj().

> Does that cover it all ?

Generally, yes.

> If so then I need to fix ``walk`` so that it *does* honour the order. Could I 
> build your functionality into ConfigObj with an optional ``copy_comments`` 
> option to the validate method ?

Nice and clean, I like it.

> You could then create your default config file by doing :
>
> from validate import Validator
> from configobj import ConfigObj
>
> vdt = Validator()
> cfg = ConfigObj(configspec=filename)
> cfg.validate(vdt, copy_comments=True)
> cfg.write()

Beautiful.

> Is there any functionality you are suggesting that I have missed ?

Nope, you seems to cover it all.

Thanks, Louis.

-- 
Louis Cordier <lco...@po...> cell: +27721472305
Point45 Entertainment (Pty) Ltd. http://www.point45.org

[Configobj-develop] Re: ConfigObj: Default config file, functionality.

[Fuzzyman <fuz...@vo...>]

Hello Louis,

Can you explain to me what this actually does (sorry for my ignorance).

You want to create a default config file from a configspec. You want to 
copy the comments from the configspec *into* the config file when this 
is done ?

You have attempted to do this with walk, but walk *doesn't* honour the 
order of the configspec, so you have implemented an alternative.

Does that cover it all ?

If so then I need to fix ``walk`` so that it *does* honour the order. 
Could I build your functionality into ConfigObj with an optional 
``copy_comments`` option to the validate method ?

You could then create your default config file by doing :

from validate import Validator
from configobj import ConfigObj

vdt = Validator()
cfg = ConfigObj(configspec=filename)
cfg.validate(vdt, copy_comments=True)
cfg.write()

Is there any functionality you are suggesting that I have missed ?

Nicola (other users/developers), are you happy for this to be built into 
ConfigObj, or would it be better as a separate function ?

``__many__`` should be ignored in the configspec - it is only used to 
validate sections that exist (of which there may be none, one or more). 
This is what ``validate`` already does.

String interpolation should be off, leaving the substitution to be done 
when values are fetched.

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Nicola Larosa wrote:
> Hi Louis, sorry for the late answer, this email somehow escaped my
> attention for a while.
>
> Thanks a lot for your contribution, it seems interesting. Michael?
>
>
> Louis Cordier wrote:
>   
>> Hi guys,
>>
>> Here is a piece of code to generate a 'default' config file
>> from the configspec. Basically it copies the comments and
>> default values while retaining the sequential order of the
>> configspec file. I can think of a few cases where one would
>> like to generate a default configfile with proper comments
>> for a user (if his/hers' are lost), while keeping them out
>> of the configspec file. The comments can list all the valid
>> values.
>>
>> For example how some X servers auto generate a default config
>> file.
>>
>> Anyway this isn't fully complete. I am not too sure how to
>> deal with [__many__] or string substitution yet.
>>
>> I also experimented (ignoring the comments) with using .walk():
>>
>>     def walker(s, k):
>>         s.defaults = []
>>
>>     validator = Validator()
>>     d = ConfigObj(options={'configspec': 'config.spec'})
>>     d.validate(validator)
>>     d.walk(walker)
>>     d.filename = 'config.ini'
>>     d.write()
>>
>> This for some reason loses the internal order of 'config.spec'.
>>
>> I think there is probably a few other people that might like this
>> functionality. You guys are welcome to add it to configobj.py
>> or put it on the webpage.
>>
>> I suspect this would be a nice way of doing it:
>>
>> c = ConfigObj(options={'configspec': 'config.spec',
>>                'include_comments': True,
>>                        'retain_order': True,
>>                        'indent_type': ' '})
>> c.validate(validator)
>> c.filename = 'config.ini'
>> c.write()
>>
>> Regards, Louis
>>
>>
>> ------------------------------------------------------------------------
>>
>> #!/usr/bin/env python
>>
>> #
>> #      author : Louis Cordier <lco...@gm...>
>> # description : Testing code for generating a default config file.
>> #    synopsis :
>> #       notes :
>> #    modified : $Id$
>> #
>>
>> from configobj import ConfigObj, ConfigObjError
>> from validate import Validator
>> from datetime import datetime
>>
>> def create_config(configspec):
>>     """ Create a default config file based on the configspec file.
>>         
>>         Load the configspec file as if it was a config file, get the order
>>         sequence of the sections, keys-value pairs and their comments.
>>         All configspec values are then interpeted as strings to be ignored.
>>         Walk the configspec and create a new config file with the default
>>         values and comments of the configspec.
>>         
>>         @note: This is a special case, [__many__] are not yet supported.
>>         
>>         @note: ConfigObj.walk() will only work on sections to copy the
>>             comments, not the complete config object.
>>             We could transverse the parent()-tree, this feels ugly though.
>>         
>>         @note: We could recursively empty all the defaults members and copy
>>             the comments, but then we loose the configspec sequence though.
>>     """
>>     
>>     def copy_section(spec_section, source_section, target_section):
>>         """ Recursive copy sections. 
>>             
>>             Copy default values from source_section to target_section
>>             and comments from spec_section to target_section.
>>             Follow the sequence as specified in spec_section.
>>         """
>>         # Deal with the root section, the config object itself.
>>         if hasattr(source_section,'initial_comment'):
>>             target_section.initial_comment = spec_section.initial_comment
>>         
>>         # Deal with the root section, the config object itself.
>>         if hasattr(source_section,'final_comment'):
>>             target_section.final_comment = spec_section.final_comment
>>         
>>         target_section.inline_comments = spec_section.inline_comments
>>         target_section.comments = spec_section.comments
>>         
>>         for key in spec_section.keys():
>>             if key in spec_section.sections:
>>                 target_section[key] = {}
>>                 copy_section(spec_section[key], source_section[key], target_section[key])
>>             else:
>>                 target_section[key] = source_section[key]
>>     
>>     
>>     try:
>>         spec = ConfigObj(infile=configspec)
>>     
>>     except (IOError), e:
>>         # The configspec file needs to exist for this to work.
>>         pass
>>     
>>     # Let this function raise configobj.ConfigObjError,
>>     # in case of a broken configspec.
>>     
>>     else:
>>         try:
>>             source = ConfigObj(options={'configspec': configspec})
>>         
>>         except (IOError), e:
>>             # The configspec file needs to exist for this to work.
>>             pass
>>         
>>         # Broken configspec, should have failed earlier already.
>>         
>>         else:
>>             # Now get all the default values.
>>             # This can only fail if the configspec is broken.
>>             validator = Validator()
>>             valid = source.validate(validator)
>>             
>>             if valid == True:
>>                 # Create a new config object to be populated.
>>                 target = ConfigObj(options={'configspec': configspec,
>>                                             'indent_type': ' '})
>>                 
>>                 copy_section(spec, source, target)
>>                 return target
>>             else:
>>                 raise ConfigObjError, "Bad configspec, '%s'" % (configspec)
>>     
>>     # It should ideally never get here.
>>     return None
>>
>>
>> if __name__ == '__main__':
>>     
>>     # Maybe put configspec in the code itself, if config.ini doesn't exist
>>     # it could write a default file with comments.
>>     try:
>>         default_config = create_config('config.spec')
>>     except (ConfigObjError), e:
>>         print 'Ooops', e
>>     else:
>>         default_config.filename = 'config.ini'
>>         default_config.initial_comment.insert(0, 'Automatically generated from %s on %sZ\n' % ('config.spec', datetime.utcnow().isoformat()))
>>         default_config.write()
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> #
>> # Main config file...
>> #
>>
>> #
>> # Server setup
>> #
>> [server]
>> active = boolean(default=True)
>> name = string(default=Michael)
>> age = float(default=0.0)
>> sex = option(m, f, default=m)
>>
>>
>> #
>> # Database setup
>> #
>> [database]
>> database = string(default=hydra)
>> host = string(default=nostromo.intranet)
>> user = string(default=hydra)
>> password = string(default=hydra)
>>
>>     #
>>     # Level 1 Comment
>>     #
>>     [[level1]]
>>     tl1=integer(default=1)
>>     
>>     #
>>     # Edit only if you know what you are doing.
>>     tl2=integer(default=2) # tl2 inline
>>     
>>     [[[test]]]
>>         test1=integer(default=1)
>>         test2=integer(default=2)
>>         
>>         [[[[sub_test]]]]
>>         # sub1
>>         sub1=integer(default=1) #sub1-inline
>>         # sub2
>>         sub2=integer(default=2) #sub2-inline
>>     
>>     #
>>     # Level 1 footer. 
>>     #
>>
>>     
>
>
>   

[Configobj-develop] Configuring Turbogears

[<fuz...@vo...>]

{emo;newspaper} `Turbogears <http://www.turbogears.com/>`_ is arguably the *hottest* [#]_ Python project there is right now.

Apparently they're having problems with their current configuration system and Python 2.3. They are/were using pseudo-python files for configuration. Yesterday I discovered this message, from Kevin Dangoor, on the Turbogears Mailing List :

    `Config File Verdict <http://groups.google.co.uk/group/turbogears/browse_frm/thread/f77979ad0e1dacd0/b97cc6d6af9439d6?tvc=1&q=turbogears+configobj#b97cc6d6af9439d6>`_

    | *So, taking into account the various bits of input and the fact that* 
    | *there would appear to be a problem with the new style configs and*
    | *Python 2.3, I'm going to change our config system over to using*
    | **ConfigObj**. 

Blimey. {sm;:-)}

I don't think it's set in stone yet, but if Turbogears switch to using `ConfigObj <http://www.voidspace.org.uk/python/configobj.html>`_ that will be fantastic news.

In the same thread, Mike Orr responds with the following comments on **ConfigObj** :

    | *It looks pretty complete.  I like the validator, conversion to ints*
    | *and lists, triple-quoted strings, and keeping the keys/values in* 
    | *order.  I suppose I should like the multi-level sections. The* 
    | *comma-separated list feature is cool, and I guess it has enough* 
    | *safeguards to distinguish lists from strings.* 

I'm not sure what he means by *should like*, but it's nice to see ConfigObj's features appreciated. {sm;:-p}

.. [#] Well, along with `Django <http://www.djangoproject.com/>`_, `BitTorrent <http://www.bittorrent.com/>`_ and a few others.

Re: [Configobj-develop] Re: ConfigObj

[Fuzzyman <fuz...@vo...>]

Nicola Larosa wrote:

>>Nicola (ConfigObj co-developer) - the last three support queries I've
>>had for ConfigObj have all been to do with empty values. It seems that a
>>lot of people are using ConfigObj to parse ini files created elsewhere.
>>
>>IIRC the empty value *is* part of the normal ini spec. (A later version
>>of ConfigObj 3 supported them.) Would you object to me extending
>>ConfigObj to read empty values ?
>>
>>A logical counterpart to this is an additional option (default False)
>>allowing you to specify that ConfigObj should write out empty values in
>>place of the empty string.
>>
>>What do you think ?
>>    
>>
>
>I don't know about the INI specs, but it seems a reasonable requirement,
>and since there are real use cases, I'd say go ahead.
>  
>

I'll implement this and do an update.

The new option/attribute to be called ``write_empty_values``.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Configobj-develop] Re: ConfigObj

[Nicola L. <ni...@te...>]

> Nicola (ConfigObj co-developer) - the last three support queries I've
> had for ConfigObj have all been to do with empty values. It seems that a
> lot of people are using ConfigObj to parse ini files created elsewhere.
> 
> IIRC the empty value *is* part of the normal ini spec. (A later version
> of ConfigObj 3 supported them.) Would you object to me extending
> ConfigObj to read empty values ?
> 
> A logical counterpart to this is an additional option (default False)
> allowing you to specify that ConfigObj should write out empty values in
> place of the empty string.
> 
> What do you think ?

I don't know about the INI specs, but it seems a reasonable requirement,
and since there are real use cases, I'd say go ahead.

-- 
Nicola Larosa - http://www.tekNico.net/

It will always be true that people that drive slower than me are morons,
and people that drive faster than me are idiots. :)
 -- Matthew Carlisle on Slashdot, December 2005