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
>