[Configobj-develop] Changes to ConfigObj in SVN

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

There is a new version of `ConfigObj 
<http://www.voidspace.org.uk/python/configobj.html>`_ nearly ready. 
ConfigObj is a powerful but simple to use module for reading, writing 
and validating 'ini style' configuration files.

All the changes, along with tests, are checked into Subversion:

* https://svn.pythonutils.python-hosting.com/trunk/pythonutils/configobj.py

There are several new features and bugfixes. If you use ConfigObj, 
particularly if you use confispecs and config file validation, then I 
would appreciate you trying out the latest version and letting me know 
if breaks anything.

New features:

* Pickle support

    Pickling a ConfigObj instance is generally a pointless exercise as 
ConfigObj is intended for persistence anyway: you can always just call 
``write``... Unfortunately pickle support is needed for use with 
libraries like Parallel Python that provided shared access between 
process using serialization. Thanks to Christian Heimes for providing 
the code.

* Hashes in configspec files broken

    Thanks to Jeffrey Barish for reporting this. Configspecs are also 
parsed by ConfigObj but have an incompatible syntax with config files. 
In order to fix this I had to turn off the parsing of inline comments in 
configspecs. This will only affect you if you are using ``copy=True`` 
when validating and expecting inline comments to be copied from the 
configspec into the ConfigObj instance (all other comments will be 
copied as usual).
   
    If you create the configspec by passing in a ConfigObj instance 
(usual way is to pass in a filename or list of lines) then you should 
pass in ``_inspec=True`` to the constructor to allow hashes in values. 
This is the magic that switches off inline comment parsing.

* Repeated values now allowed in configspecs

    You have always been able to specify that all sections (or 
sub-sections) in a config file are to be validated with the same 
specification by providing a ``__many__`` section in the configspec.
   
    You can now specify that all values in a section / sub-section 
should be validated with the same specification by providing 
``__many__`` as a value. If you want to use this feature in a section 
that also has a ``__many__`` sub-section then the repeated value can be 
called ``___many___`` (note the triple underscores) instead.
   
    As an example, the following configspec specifies that every value 
in a config file (and every section it contains) must be an integer: ::
   
        ___many___ = integer
        [__many__]
        __many__ = integer

* Expected sections as scalars or vice-versa

    Under the current version of ConfigObj, if your configspec specifies 
a section and a scalar value is supplied instead - or vice-versa - then 
ConfigObj will crash. This is now fixed (but the config file is still 
screwed).

   
In the process of working on the configspec handling code to implement 
the new feature and the bugfixes I ripped out and reimplemented most of 
it (thanks Nicola Larosa for making me write tests!). I discovered a 
couple of restrictions on how you can write config file specifications 
that were merely an artifact of how the code was written. The code is 
now simpler and several restrictions have been removed:

* Previously a ``__many__`` section had to be the only sub-section in a 
section - now ``__many__`` can appear alongside other sections and will 
only be used to validate sub-sections that don't have an explicit 
validation section.
* You can now create an empty ConfigObj with a configspec, 
programmatically set values and then validate. This would only partly 
work before.

Despite the rewrite and these changes the API is almost entirely 
unchanged. The major change is that when you create a ConfigObj instance 
and provide a configspec, the ``configspec`` attribute is only set on 
the ConfigObj instance - it isn't set on the sections until you set 
validate. You also can't set the ``configspec`` attribute to be a 
dictionary. This wasn't documented but did work previously.
   
The next release will be 4.6.0 and will follow soon. There are also 
minor changes to `validate 
<http://www.voidspace.org.uk/python/validate.html>`_. These are minor 
changes that should be backwards compatible; in order to get the tests 
passing under Python 2.5 & 2.6.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog