configobj-develop — Support and development of ConfigObj

Re: [Configobj-develop] Parse error with valid config file

[<mai...@op...>]

Zitat von Michael Foord <fuz...@vo...>:

> mai...@op... wrote:
>> Hi,
>>
>> i have a problem starting elisa with follow error that come from
>> configobj (i think)
>
> I've just tested that config file with ConfigObj 4.5.3 and it reads
> fine. What version of ConfigObj does Elisa use?

Where can i see this? it begins with:

# configobj.py
# A config file reader/writer that supports nested sections in config files.
# Copyright (C) 2005-2006 Michael Foord, Nicola Larosa
# E-mail: fuzzyman AT voidspace DOT org DOT uk
#         nico AT tekNico DOT net

# ConfigObj 4

  - i have updated ConfigObj to 4.5.3 and its not working to. How can  
i test what is wrong? Do i have Python compiled wrong?

>
> Michael Foord
>>
>> the code, elisa uses is (./elisa/core/config.py):
>>
>>         self.info("Using %r config file", config_file)
>>         try:
>>             self._config = ConfigObj(config_file, unrepr=True)
>>         except ConfigObjError, ex:
>>             errors = [ error.message for error in ex.errors ]
>>             errors = ';'.join(errors)
>>             raise ConfigError("Config format error in %s: %s" %
>> (config_file,
>>                                                                  errors))
>>
>> the error i become is:
>>
>> File "build/lib.linux-i686-2.5/twisted/internet/base.py", line
>> 705, in runUntilCurrent
>>
>>
>>                                     File "/usr/bin/elisa", line 153,
>> in _start_application
>>
>>                                                 options=options)
>>
>>                                                           File
>> "/usr/lib/python2.5/site-packages/elisa/core/application.py", line
>> 269, in __init__
>>
>>
>>                                                                     File
>> "/usr/lib/python2.5/site-packages/elisa/core/application.py", line
>> 165, in __init__
>>
>>
>>
>>         File
>> "/usr/lib/python2.5/site-packages/elisa/core/application.py", line
>> 209, in _load_config
>>
>>
>>
>> File "/usr/lib/python2.5/site-packages/elisa/core/config.py", line 92,
>> in __init__
>>
>>
>>
>>       elisa.core.config.ConfigError: Config format error in
>> /storage/.elisa-0.5/elisa_0_5_6.conf: Parse error in value at line
>> 2.;Parse error in
>> value at line 3.;Parse error in value at line 4.;Parse error in value
>> at line 5.;Parse
>> error in value at line 7.;Parse error in value at line 10.;Parse error
>> in value at line
>> 11.;Parse error in value at line 12.;Parse error in value at line
>> 15.;Parse error in
>> value at line 16.;Parse error in value at line 17.
>>
>>
>>
>>        (twisted/internet/base.py:707)
>>
>> i have build my complete Distribution incl. Python-2.5.2 with uClibc
>> from Scratch. Where can be my problem?
>>
>> Stephan
>> i have attached the configfile, that elisa creates, it looks valid.
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win   
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Configobj-develop mailing list
>> Con...@li...
>> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>>
>
>
> --
> http://www.ironpythoninaction.com/
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>

Re: [Configobj-develop] Parse error with valid config file

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

mai...@op... wrote:
> Hi,
>
> i have a problem starting elisa with follow error that come from 
> configobj (i think)

I've just tested that config file with ConfigObj 4.5.3 and it reads 
fine. What version of ConfigObj does Elisa use?

Michael Foord
>
> the code, elisa uses is (./elisa/core/config.py):
>
>         self.info("Using %r config file", config_file)
>         try:
>             self._config = ConfigObj(config_file, unrepr=True)
>         except ConfigObjError, ex:
>             errors = [ error.message for error in ex.errors ]
>             errors = ';'.join(errors)
>             raise ConfigError("Config format error in %s: %s" % 
> (config_file,
>                                                                  errors))
>
> the error i become is:
>
> File "build/lib.linux-i686-2.5/twisted/internet/base.py", line
> 705, in runUntilCurrent
>
>
>                                     File "/usr/bin/elisa", line 153, 
> in _start_application
>
>                                                 options=options)
>
>                                                           File
> "/usr/lib/python2.5/site-packages/elisa/core/application.py", line 
> 269, in __init__
>
>
>                                                                     File
> "/usr/lib/python2.5/site-packages/elisa/core/application.py", line 
> 165, in __init__
>
>
>                                                                       
>         File
> "/usr/lib/python2.5/site-packages/elisa/core/application.py", line 
> 209, in _load_config
>
>
>
> File "/usr/lib/python2.5/site-packages/elisa/core/config.py", line 92, 
> in __init__
>
>
>
>       elisa.core.config.ConfigError: Config format error in
> /storage/.elisa-0.5/elisa_0_5_6.conf: Parse error in value at line 
> 2.;Parse error in
> value at line 3.;Parse error in value at line 4.;Parse error in value 
> at line 5.;Parse
> error in value at line 7.;Parse error in value at line 10.;Parse error 
> in value at line
> 11.;Parse error in value at line 12.;Parse error in value at line 
> 15.;Parse error in
> value at line 16.;Parse error in value at line 17.
>
>
>
>        (twisted/internet/base.py:707)
>
> i have build my complete Distribution incl. Python-2.5.2 with uClibc 
> from Scratch. Where can be my problem?
>
> Stephan
> i have attached the configfile, that elisa creates, it looks valid.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>   


-- 
http://www.ironpythoninaction.com/

[Configobj-develop] Parse error with valid config file

[<mai...@op...>]

Hi,

i have a problem starting elisa with follow error that come from  
configobj (i think)

the code, elisa uses is (./elisa/core/config.py):

         self.info("Using %r config file", config_file)
         try:
             self._config = ConfigObj(config_file, unrepr=True)
         except ConfigObjError, ex:
             errors = [ error.message for error in ex.errors ]
             errors = ';'.join(errors)
             raise ConfigError("Config format error in %s: %s" % (config_file,
                                                                  errors))

the error i become is:

File "build/lib.linux-i686-2.5/twisted/internet/base.py", line
705, in runUntilCurrent


                                     File "/usr/bin/elisa", line 153,  
in _start_application

                                                 options=options)

                                                           File
"/usr/lib/python2.5/site-packages/elisa/core/application.py", line  
269, in __init__


                                                                     File
"/usr/lib/python2.5/site-packages/elisa/core/application.py", line  
165, in __init__


                                                                        
         File
"/usr/lib/python2.5/site-packages/elisa/core/application.py", line  
209, in _load_config



File "/usr/lib/python2.5/site-packages/elisa/core/config.py", line 92,  
in __init__



       elisa.core.config.ConfigError: Config format error in
/storage/.elisa-0.5/elisa_0_5_6.conf: Parse error in value at line  
2.;Parse error in
value at line 3.;Parse error in value at line 4.;Parse error in value  
at line 5.;Parse
error in value at line 7.;Parse error in value at line 10.;Parse error  
in value at line
11.;Parse error in value at line 12.;Parse error in value at line  
15.;Parse error in
value at line 16.;Parse error in value at line 17.



        (twisted/internet/base.py:707)

i have build my complete Distribution incl. Python-2.5.2 with uClibc  
from Scratch. Where can be my problem?

Stephan
i have attached the configfile, that elisa creates, it looks valid.

Re: [Configobj-develop] Changes to ConfigObj in SVN

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

Steve Lee wrote:
> 2008/10/27 Michael Foord <fuz...@vo...>:
>   
>> 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.
>>     
>
> Sorry for the delay
>
> No problems seen.
> The bug with # in the value for defaults and subsequently in the ini
> file looks fixed to me
>
>   
Great.

Michael

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

Re: [Configobj-develop] Changes to ConfigObj in SVN

[Steve L. <st...@fu...>]

2008/10/27 Michael Foord <fuz...@vo...>:
> 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.

Sorry for the delay

No problems seen.
The bug with # in the value for defaults and subsequently in the ini
file looks fixed to me

-- 
Steve Lee
Open Source Assistive Technology Software and Accessibility
fullmeasure.co.uk

Re: [Configobj-develop] ConfigObj and pickle bug

[Christian H. <c.h...@se...>]

Michael Foord wrote:
> Hello Christian,
> 
> The second patch you proposed is in subversion with a minimal test as 
> well. There are various other changes to ConfigObj - all around the 
> handling of configspecs, so I'd appreciate you checking that there are 
> no issues with the new version.
> 
> https://svn.pythonutils.python-hosting.com/trunk/pythonutils/configobj.py
> 
> All the best,

I'll review the changes today.

Christian

PS: I'm getting a ssl_error_bad_cert_domain "*.webfaction.com , 
webfaction.com" for your server https://svn.pythonutils.python-hosting.com/

Re: [Configobj-develop] Changes to ConfigObj in SVN

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

Michael Foord wrote:
> There is a new version of `ConfigObj
> <http://www.voidspace.org.uk/python/configobj.html>`_ nearly ready.
> ...
> (thanks Nicola Larosa for making me write tests!)

My pleasure. ;-) Sorry that I'm not that much active on this project
anymore, but I still follow it.

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

To leave out the fact that violent crime is a generally male mode
of expression, is not so much to ignore the Elephant in the room,
as to have incorporated its presence to such a degree that it is
now an intrinsic part of the decor. - Amanda Dean, June 2008

[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

Re: [Configobj-develop] ConfigObj and pickle bug

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

Hello Christian,

The second patch you proposed is in subversion with a minimal test as 
well. There are various other changes to ConfigObj - all around the 
handling of configspecs, so I'd appreciate you checking that there are 
no issues with the new version.

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

All the best,

Michael Foord

Christian Heimes wrote:
> Dear Michael!
>
> I run into some trouble when I used a ConfigObj object as an argument 
> to parallel python. After some debugging I spotted a design issue in 
> your code.
>
> configobj.Section is a subclass of dict but it doesn't overwrite the 
> pickle hook __reduce__. Pickling a section or configobj keeps the data 
> in self (aka the dict) but not the data in self.__dict__. I came up 
> with a quick hotfix for the problem.
>
> # ---
> import configobj
> import copy_reg
>
> def configobj_factory(cls):
>     return cls.__new__(cls)
>
> copy_reg.constructor(configobj_factory)
>
> class SectionPatch(object):
>
>     def __setstate__(self, state):
>         dict.update(self, state[0])
>         self.__dict__.update(state[1])
>
>     def __reduce__(self):
>         state = (dict(self), dict(self.__dict__))
>         return (configobj_factory, (self.__class__, ), state)
>
> def patch(cls, patchcls):
>     bases = cls.__bases__
>     if not patchcls in bases:
>         cls.__bases__ = (patchcls,) + bases
>
> patch(configobj.Section, SectionPatch)
> # ---
>
> Greeting
> Christian


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

Re: [Configobj-develop] problem with default values

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

Steve Lee wrote:
> Hi I've just discovered configObj through some software I'm working on
> and find it very useful and well designed
>
> However I have a problem with using # in default strings
>
> colour = string(default="#ff00dd")
>
> errors. It appears the # is incorrectly being interpreted as a
> comment, and looks like a bug in the regular expression.
>
> Is this a known problem and does it have a workaround? I can't see any
> way to have a literal #
>
>   

Damn - so it turns out that the only way to tell if a hash is inside 
quotes or a comment marker is to parse the string fully. As most of the 
parsing (pulling out list values with or without quotes etc) is done 
inside validate it would be 'inconvenient' to move this inside ConfigObj.

This is because configspecs actually have a slightly different syntax to 
normal ConfigObj - even with 'list_values' set to False this is invalid 
syntax:

    name = string(default="#ff00dd")

You can actually get round this by using triple  quotes:

    name = '''string(default="#ff00dd")'''

Slightly ugly but it works. I'm working on a longer term fix where 
ConfigObj won't parse comments in configspecs - and let validate remove 
them instead (implementing support for comments in validate itself).

Michael
> thanks
>
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

Re: [Configobj-develop] problem with default values

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

Steve Lee wrote:
> Hi I've just discovered configObj through some software I'm working on
> and find it very useful and well designed
>
> However I have a problem with using # in default strings
>
> colour = string(default="#ff00dd")
>
> errors. It appears the # is incorrectly being interpreted as a
> comment, and looks like a bug in the regular expression.
>
> Is this a known problem and does it have a workaround? I can't see any
> way to have a literal #
>
> thanks
>
>   

No - not a known problem. Damn.

Thanks for the report - I'll get a fix as soon as possible. Patches with 
tests welcomed of course.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

[Configobj-develop] problem with default values

[Steve L. <st...@fu...>]

Hi I've just discovered configObj through some software I'm working on
and find it very useful and well designed

However I have a problem with using # in default strings

colour = string(default="#ff00dd")

errors. It appears the # is incorrectly being interpreted as a
comment, and looks like a bug in the regular expression.

Is this a known problem and does it have a workaround? I can't see any
way to have a literal #

thanks

-- 
Steve Lee
Open Source Assistive Technology Software and Accessibility
fullmeasure.co.uk

Re: [Configobj-develop] Problem with unrepr mode

[Jeffrey B. <jef...@ea...>]

On Sunday 21 September 2008 14:01:48 Michael Foord wrote:
> Jeffrey Barish wrote:
> > On Sunday 21 September 2008 13:25:27 Michael Foord wrote:
> >> Jeffrey Barish wrote:
> >>> On Sunday 21 September 2008 11:30:36 Michael Foord wrote:
> >>>> Jeffrey Barish wrote:
> >>>>> On Sunday 21 September 2008 04:17:50 Michael Foord wrote:
> >>>>>> Jeffrey Barish wrote:
> >>>>>>> On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
> >>>>>>>> Configobj was working fine until I switched to using unrepr mode.
> >>>>>>>> Now it works fine on one platform, but on another the same code
> >>>>>>>> produces the following error:
> >>>>>>>>
> >>>>>>>>   ...
> >>>>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272,
> >>>>>>>> in __init__ self._load(infile, configspec)
> >>>>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355,
> >>>>>>>> in _load raise error
> >>>>>>>> configobj.ConfigObjError: Parsing failed with several errors.
> >>>>>>>> First error at line 3.
> >>>>>>>>
> >>>>>>>> Line 3 is:
> >>>>>>>>
> >>>>>>>> v = 0.77304964539007093
> >>>>>>>>
> >>>>>>>> I am using version 4.5.3 on python 2.5.2.  Considering that the
> >>>>>>>> same rc file works fine on the other platform, I am at a loss as
> >>>>>>>> to what to do. Any suggestions?
> >>>>>>>
> >>>>>>> The problem appears to arise because there is no compiler module on
> >>>>>>> this platform (Nokia N800).
> >>>>>>>
> >>>>>>> Do I have any options other than returning to code like
> >>>>>>>
> >>>>>>> if x == 'True'
> >>>>>>
> >>>>>> unrepr mode relies on the compiler module - so it won't work on a
> >>>>>> platform that doesn't provide it.
> >>>>>>
> >>>>>> You could use validate and a configspec to convert types instead.
> >>>>>>
> >>>>>>
> >>>>>> Michael
> >>>>>
> >>>>> OK.  I learned how to use validate.  It works nicely for converting
> >>>>> types and I am also doing range checking, so it's a better solution
> >>>>> anyway.
> >>>>>
> >>>>> One problem, though.  In my configuration file I have a section with
> >>>>> colors, but I don't know a priori what colors it will contain.  For
> >>>>> example:
> >>>>>
> >>>>> [colors]
> >>>>> color1 = [143, 188, 143]
> >>>>> color2 = [70, 130, 180]
> >>>>>
> >>>>> and so on.  Since I don't know what the keys are going to be, I
> >>>>> presume that there is no way for me to validate the entries.  Is that
> >>>>> true?  It would be nice to be able to test that values are between 0
> >>>>> and 255 and to convert the strings to integers and the brackets to a
> >>>>> list. Currently I am doing
> >>>>>
> >>>>> color1 = 143, 188, 143
> >>>>>
> >>>>> and not validating.
> >>>>
> >>>> You're correct that ConfigObj doesn't support validating arbitrary
> >>>> entries in a section. It is a worthy feature request though (perhaps
> >>>> "* = check()").
> >>>>
> >>>> I'll add it to my list - but as I am *still* finishing a book it will
> >>>> be quicker if someone else implements it. It will need to be in the
> >>>> ConfigObj.validate method rather than in the validate module.
> >>>>
> >>>> Michael
> >>>
> >>> Here's a worse problem: after using config.reload(), all values revert
> >>> to strings.  I have to revalidate after every reload to get values back
> >>> into their correct types.
> >>
> >> Hmmm... that sounds like correct behaviour to me. Validation is an
> >> explicit step.
> >>
> >> Michael
> >
> > You make a good point.  But consider: If I provided a configspec when I
> > created the ConfigObj and I then validated the ConfigObj, would it ever
> > happen that I would not want the ConfigObj validated again when I call
> > reload?  If someone really wanted the values to revert to strings, it
> > seems to me that he would create a new ConfigObj (without a configspec)
> > rather than call reload.  I see reload as a shortcut for refreshing the
> > values using the same procedure I used initially to create them.
>
> On the other hand, validation requires a validator - and having reload
> do an implicit validate would require us to keep a reference to the
> validator used the first time. This may or may not keep a lot of memory
> in use unnecessarily or even potentially cause us to reuse an object not
> in a valid state.
>
> I see reload as returning the ConfigObj instance to the state
> immediately after loading - which would be before validation. Is calling
> validate again really such a big burden?
>
>
> Michael

It's not a problem.  Thanks for explaining the issues.
-- 
Jeffrey Barish

Re: [Configobj-develop] Problem with unrepr mode

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

Jeffrey Barish wrote:
> On Sunday 21 September 2008 13:25:27 Michael Foord wrote:
>   
>> Jeffrey Barish wrote:
>>     
>>> On Sunday 21 September 2008 11:30:36 Michael Foord wrote:
>>>       
>>>> Jeffrey Barish wrote:
>>>>         
>>>>> On Sunday 21 September 2008 04:17:50 Michael Foord wrote:
>>>>>           
>>>>>> Jeffrey Barish wrote:
>>>>>>             
>>>>>>> On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
>>>>>>>               
>>>>>>>> Configobj was working fine until I switched to using unrepr mode. 
>>>>>>>> Now it works fine on one platform, but on another the same code
>>>>>>>> produces the following error:
>>>>>>>>
>>>>>>>>   ...
>>>>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272,
>>>>>>>> in __init__ self._load(infile, configspec)
>>>>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355,
>>>>>>>> in _load raise error
>>>>>>>> configobj.ConfigObjError: Parsing failed with several errors.
>>>>>>>> First error at line 3.
>>>>>>>>
>>>>>>>> Line 3 is:
>>>>>>>>
>>>>>>>> v = 0.77304964539007093
>>>>>>>>
>>>>>>>> I am using version 4.5.3 on python 2.5.2.  Considering that the same
>>>>>>>> rc file works fine on the other platform, I am at a loss as to what
>>>>>>>> to do. Any suggestions?
>>>>>>>>                 
>>>>>>> The problem appears to arise because there is no compiler module on
>>>>>>> this platform (Nokia N800).
>>>>>>>
>>>>>>> Do I have any options other than returning to code like
>>>>>>>
>>>>>>> if x == 'True'
>>>>>>>               
>>>>>> unrepr mode relies on the compiler module - so it won't work on a
>>>>>> platform that doesn't provide it.
>>>>>>
>>>>>> You could use validate and a configspec to convert types instead.
>>>>>>
>>>>>>
>>>>>> Michael
>>>>>>             
>>>>> OK.  I learned how to use validate.  It works nicely for converting
>>>>> types and I am also doing range checking, so it's a better solution
>>>>> anyway.
>>>>>
>>>>> One problem, though.  In my configuration file I have a section with
>>>>> colors, but I don't know a priori what colors it will contain.  For
>>>>> example:
>>>>>
>>>>> [colors]
>>>>> color1 = [143, 188, 143]
>>>>> color2 = [70, 130, 180]
>>>>>
>>>>> and so on.  Since I don't know what the keys are going to be, I presume
>>>>> that there is no way for me to validate the entries.  Is that true?  It
>>>>> would be nice to be able to test that values are between 0 and 255 and
>>>>> to convert the strings to integers and the brackets to a list. 
>>>>> Currently I am doing
>>>>>
>>>>> color1 = 143, 188, 143
>>>>>
>>>>> and not validating.
>>>>>           
>>>> You're correct that ConfigObj doesn't support validating arbitrary
>>>> entries in a section. It is a worthy feature request though (perhaps "*
>>>> = check()").
>>>>
>>>> I'll add it to my list - but as I am *still* finishing a book it will be
>>>> quicker if someone else implements it. It will need to be in the
>>>> ConfigObj.validate method rather than in the validate module.
>>>>
>>>> Michael
>>>>         
>>> Here's a worse problem: after using config.reload(), all values revert to
>>> strings.  I have to revalidate after every reload to get values back into
>>> their correct types.
>>>       
>> Hmmm... that sounds like correct behaviour to me. Validation is an
>> explicit step.
>>
>> Michael
>>     
>
> You make a good point.  But consider: If I provided a configspec when I 
> created the ConfigObj and I then validated the ConfigObj, would it ever 
> happen that I would not want the ConfigObj validated again when I call 
> reload?  If someone really wanted the values to revert to strings, it seems 
> to me that he would create a new ConfigObj (without a configspec) rather than 
> call reload.  I see reload as a shortcut for refreshing the values using the 
> same procedure I used initially to create them.

On the other hand, validation requires a validator - and having reload 
do an implicit validate would require us to keep a reference to the 
validator used the first time. This may or may not keep a lot of memory 
in use unnecessarily or even potentially cause us to reuse an object not 
in a valid state.

I see reload as returning the ConfigObj instance to the state 
immediately after loading - which would be before validation. Is calling 
validate again really such a big burden?


Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

Re: [Configobj-develop] Problem with unrepr mode

[Jeffrey B. <jef...@ea...>]

On Sunday 21 September 2008 13:25:27 Michael Foord wrote:
> Jeffrey Barish wrote:
> > On Sunday 21 September 2008 11:30:36 Michael Foord wrote:
> >> Jeffrey Barish wrote:
> >>> On Sunday 21 September 2008 04:17:50 Michael Foord wrote:
> >>>> Jeffrey Barish wrote:
> >>>>> On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
> >>>>>> Configobj was working fine until I switched to using unrepr mode. 
> >>>>>> Now it works fine on one platform, but on another the same code
> >>>>>> produces the following error:
> >>>>>>
> >>>>>>   ...
> >>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272,
> >>>>>> in __init__ self._load(infile, configspec)
> >>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355,
> >>>>>> in _load raise error
> >>>>>> configobj.ConfigObjError: Parsing failed with several errors.
> >>>>>> First error at line 3.
> >>>>>>
> >>>>>> Line 3 is:
> >>>>>>
> >>>>>> v = 0.77304964539007093
> >>>>>>
> >>>>>> I am using version 4.5.3 on python 2.5.2.  Considering that the same
> >>>>>> rc file works fine on the other platform, I am at a loss as to what
> >>>>>> to do. Any suggestions?
> >>>>>
> >>>>> The problem appears to arise because there is no compiler module on
> >>>>> this platform (Nokia N800).
> >>>>>
> >>>>> Do I have any options other than returning to code like
> >>>>>
> >>>>> if x == 'True'
> >>>>
> >>>> unrepr mode relies on the compiler module - so it won't work on a
> >>>> platform that doesn't provide it.
> >>>>
> >>>> You could use validate and a configspec to convert types instead.
> >>>>
> >>>>
> >>>> Michael
> >>>
> >>> OK.  I learned how to use validate.  It works nicely for converting
> >>> types and I am also doing range checking, so it's a better solution
> >>> anyway.
> >>>
> >>> One problem, though.  In my configuration file I have a section with
> >>> colors, but I don't know a priori what colors it will contain.  For
> >>> example:
> >>>
> >>> [colors]
> >>> color1 = [143, 188, 143]
> >>> color2 = [70, 130, 180]
> >>>
> >>> and so on.  Since I don't know what the keys are going to be, I presume
> >>> that there is no way for me to validate the entries.  Is that true?  It
> >>> would be nice to be able to test that values are between 0 and 255 and
> >>> to convert the strings to integers and the brackets to a list. 
> >>> Currently I am doing
> >>>
> >>> color1 = 143, 188, 143
> >>>
> >>> and not validating.
> >>
> >> You're correct that ConfigObj doesn't support validating arbitrary
> >> entries in a section. It is a worthy feature request though (perhaps "*
> >> = check()").
> >>
> >> I'll add it to my list - but as I am *still* finishing a book it will be
> >> quicker if someone else implements it. It will need to be in the
> >> ConfigObj.validate method rather than in the validate module.
> >>
> >> Michael
> >
> > Here's a worse problem: after using config.reload(), all values revert to
> > strings.  I have to revalidate after every reload to get values back into
> > their correct types.
>
> Hmmm... that sounds like correct behaviour to me. Validation is an
> explicit step.
>
> Michael

You make a good point.  But consider: If I provided a configspec when I 
created the ConfigObj and I then validated the ConfigObj, would it ever 
happen that I would not want the ConfigObj validated again when I call 
reload?  If someone really wanted the values to revert to strings, it seems 
to me that he would create a new ConfigObj (without a configspec) rather than 
call reload.  I see reload as a shortcut for refreshing the values using the 
same procedure I used initially to create them.
-- 
Jeffrey Barish

Re: [Configobj-develop] Problem with unrepr mode

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

Jeffrey Barish wrote:
> On Sunday 21 September 2008 11:30:36 Michael Foord wrote:
>   
>> Jeffrey Barish wrote:
>>     
>>> On Sunday 21 September 2008 04:17:50 Michael Foord wrote:
>>>       
>>>> Jeffrey Barish wrote:
>>>>         
>>>>> On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
>>>>>           
>>>>>> Configobj was working fine until I switched to using unrepr mode.  Now
>>>>>> it works fine on one platform, but on another the same code produces
>>>>>> the following error:
>>>>>>
>>>>>>   ...
>>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272, in
>>>>>> __init__ self._load(infile, configspec)
>>>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355, in
>>>>>> _load raise error
>>>>>> configobj.ConfigObjError: Parsing failed with several errors.
>>>>>> First error at line 3.
>>>>>>
>>>>>> Line 3 is:
>>>>>>
>>>>>> v = 0.77304964539007093
>>>>>>
>>>>>> I am using version 4.5.3 on python 2.5.2.  Considering that the same
>>>>>> rc file works fine on the other platform, I am at a loss as to what to
>>>>>> do. Any suggestions?
>>>>>>             
>>>>> The problem appears to arise because there is no compiler module on
>>>>> this platform (Nokia N800).
>>>>>
>>>>> Do I have any options other than returning to code like
>>>>>
>>>>> if x == 'True'
>>>>>           
>>>> unrepr mode relies on the compiler module - so it won't work on a
>>>> platform that doesn't provide it.
>>>>
>>>> You could use validate and a configspec to convert types instead.
>>>>
>>>>
>>>> Michael
>>>>         
>>> OK.  I learned how to use validate.  It works nicely for converting types
>>> and I am also doing range checking, so it's a better solution anyway.
>>>
>>> One problem, though.  In my configuration file I have a section with
>>> colors, but I don't know a priori what colors it will contain.  For
>>> example:
>>>
>>> [colors]
>>> color1 = [143, 188, 143]
>>> color2 = [70, 130, 180]
>>>
>>> and so on.  Since I don't know what the keys are going to be, I presume
>>> that there is no way for me to validate the entries.  Is that true?  It
>>> would be nice to be able to test that values are between 0 and 255 and to
>>> convert the strings to integers and the brackets to a list.  Currently I
>>> am doing
>>>
>>> color1 = 143, 188, 143
>>>
>>> and not validating.
>>>       
>> You're correct that ConfigObj doesn't support validating arbitrary
>> entries in a section. It is a worthy feature request though (perhaps "*
>> = check()").
>>
>> I'll add it to my list - but as I am *still* finishing a book it will be
>> quicker if someone else implements it. It will need to be in the
>> ConfigObj.validate method rather than in the validate module.
>>
>> Michael
>>     
>
> Here's a worse problem: after using config.reload(), all values revert to 
> strings.  I have to revalidate after every reload to get values back into 
> their correct types.
>   
Hmmm... that sounds like correct behaviour to me. Validation is an 
explicit step.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

Re: [Configobj-develop] Problem with unrepr mode

[Jeffrey B. <jef...@ea...>]

On Sunday 21 September 2008 11:30:36 Michael Foord wrote:
> Jeffrey Barish wrote:
> > On Sunday 21 September 2008 04:17:50 Michael Foord wrote:
> >> Jeffrey Barish wrote:
> >>> On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
> >>>> Configobj was working fine until I switched to using unrepr mode.  Now
> >>>> it works fine on one platform, but on another the same code produces
> >>>> the following error:
> >>>>
> >>>>   ...
> >>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272, in
> >>>> __init__ self._load(infile, configspec)
> >>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355, in
> >>>> _load raise error
> >>>> configobj.ConfigObjError: Parsing failed with several errors.
> >>>> First error at line 3.
> >>>>
> >>>> Line 3 is:
> >>>>
> >>>> v = 0.77304964539007093
> >>>>
> >>>> I am using version 4.5.3 on python 2.5.2.  Considering that the same
> >>>> rc file works fine on the other platform, I am at a loss as to what to
> >>>> do. Any suggestions?
> >>>
> >>> The problem appears to arise because there is no compiler module on
> >>> this platform (Nokia N800).
> >>>
> >>> Do I have any options other than returning to code like
> >>>
> >>> if x == 'True'
> >>
> >> unrepr mode relies on the compiler module - so it won't work on a
> >> platform that doesn't provide it.
> >>
> >> You could use validate and a configspec to convert types instead.
> >>
> >>
> >> Michael
> >
> > OK.  I learned how to use validate.  It works nicely for converting types
> > and I am also doing range checking, so it's a better solution anyway.
> >
> > One problem, though.  In my configuration file I have a section with
> > colors, but I don't know a priori what colors it will contain.  For
> > example:
> >
> > [colors]
> > color1 = [143, 188, 143]
> > color2 = [70, 130, 180]
> >
> > and so on.  Since I don't know what the keys are going to be, I presume
> > that there is no way for me to validate the entries.  Is that true?  It
> > would be nice to be able to test that values are between 0 and 255 and to
> > convert the strings to integers and the brackets to a list.  Currently I
> > am doing
> >
> > color1 = 143, 188, 143
> >
> > and not validating.
>
> You're correct that ConfigObj doesn't support validating arbitrary
> entries in a section. It is a worthy feature request though (perhaps "*
> = check()").
>
> I'll add it to my list - but as I am *still* finishing a book it will be
> quicker if someone else implements it. It will need to be in the
> ConfigObj.validate method rather than in the validate module.
>
> Michael

Here's a worse problem: after using config.reload(), all values revert to 
strings.  I have to revalidate after every reload to get values back into 
their correct types.
-- 
Jeffrey Barish

Re: [Configobj-develop] Problem with unrepr mode

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

Jeffrey Barish wrote:
> On Sunday 21 September 2008 04:17:50 Michael Foord wrote:
>   
>> Jeffrey Barish wrote:
>>     
>>> On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
>>>       
>>>> Configobj was working fine until I switched to using unrepr mode.  Now
>>>> it works fine on one platform, but on another the same code produces the
>>>> following error:
>>>>
>>>>   ...
>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272, in
>>>> __init__ self._load(infile, configspec)
>>>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355, in
>>>> _load raise error
>>>> configobj.ConfigObjError: Parsing failed with several errors.
>>>> First error at line 3.
>>>>
>>>> Line 3 is:
>>>>
>>>> v = 0.77304964539007093
>>>>
>>>> I am using version 4.5.3 on python 2.5.2.  Considering that the same rc
>>>> file works fine on the other platform, I am at a loss as to what to do.
>>>> Any suggestions?
>>>>         
>>> The problem appears to arise because there is no compiler module on this
>>> platform (Nokia N800).
>>>
>>> Do I have any options other than returning to code like
>>>
>>> if x == 'True'
>>>       
>> unrepr mode relies on the compiler module - so it won't work on a
>> platform that doesn't provide it.
>>
>> You could use validate and a configspec to convert types instead.
>>
>>
>> Michael
>>     
>
> OK.  I learned how to use validate.  It works nicely for converting types and 
> I am also doing range checking, so it's a better solution anyway.
>
> One problem, though.  In my configuration file I have a section with colors, 
> but I don't know a priori what colors it will contain.  For example:
>
> [colors]
> color1 = [143, 188, 143]
> color2 = [70, 130, 180]
>
> and so on.  Since I don't know what the keys are going to be, I presume that 
> there is no way for me to validate the entries.  Is that true?  It would be 
> nice to be able to test that values are between 0 and 255 and to convert the 
> strings to integers and the brackets to a list.  Currently I am doing
>
> color1 = 143, 188, 143
>
> and not validating.
>   

You're correct that ConfigObj doesn't support validating arbitrary 
entries in a section. It is a worthy feature request though (perhaps "* 
= check()").

I'll add it to my list - but as I am *still* finishing a book it will be 
quicker if someone else implements it. It will need to be in the 
ConfigObj.validate method rather than in the validate module.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

Re: [Configobj-develop] Problem with unrepr mode

[Jeffrey B. <jef...@ea...>]

On Sunday 21 September 2008 04:17:50 Michael Foord wrote:
> Jeffrey Barish wrote:
> > On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
> >> Configobj was working fine until I switched to using unrepr mode.  Now
> >> it works fine on one platform, but on another the same code produces the
> >> following error:
> >>
> >>   ...
> >>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272, in
> >> __init__ self._load(infile, configspec)
> >>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355, in
> >> _load raise error
> >> configobj.ConfigObjError: Parsing failed with several errors.
> >> First error at line 3.
> >>
> >> Line 3 is:
> >>
> >> v = 0.77304964539007093
> >>
> >> I am using version 4.5.3 on python 2.5.2.  Considering that the same rc
> >> file works fine on the other platform, I am at a loss as to what to do.
> >> Any suggestions?
> >
> > The problem appears to arise because there is no compiler module on this
> > platform (Nokia N800).
> >
> > Do I have any options other than returning to code like
> >
> > if x == 'True'
>
> unrepr mode relies on the compiler module - so it won't work on a
> platform that doesn't provide it.
>
> You could use validate and a configspec to convert types instead.
>
>
> Michael

OK.  I learned how to use validate.  It works nicely for converting types and 
I am also doing range checking, so it's a better solution anyway.

One problem, though.  In my configuration file I have a section with colors, 
but I don't know a priori what colors it will contain.  For example:

[colors]
color1 = [143, 188, 143]
color2 = [70, 130, 180]

and so on.  Since I don't know what the keys are going to be, I presume that 
there is no way for me to validate the entries.  Is that true?  It would be 
nice to be able to test that values are between 0 and 255 and to convert the 
strings to integers and the brackets to a list.  Currently I am doing

color1 = 143, 188, 143

and not validating.
-- 
Jeffrey Barish

Re: [Configobj-develop] Problem with unrepr mode

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

Jeffrey Barish wrote:
> On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
>   
>> Configobj was working fine until I switched to using unrepr mode.  Now it
>> works fine on one platform, but on another the same code produces the
>> following error:
>>
>>   ...
>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272, in
>> __init__ self._load(infile, configspec)
>>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355, in _load
>>     raise error
>> configobj.ConfigObjError: Parsing failed with several errors.
>> First error at line 3.
>>
>> Line 3 is:
>>
>> v = 0.77304964539007093
>>
>> I am using version 4.5.3 on python 2.5.2.  Considering that the same rc
>> file works fine on the other platform, I am at a loss as to what to do. 
>> Any suggestions?
>>     
>
> The problem appears to arise because there is no compiler module on this 
> platform (Nokia N800).
>
> Do I have any options other than returning to code like
>
> if x == 'True'
>   

unrepr mode relies on the compiler module - so it won't work on a 
platform that doesn't provide it.

You could use validate and a configspec to convert types instead.


Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

Re: [Configobj-develop] Problem with unrepr mode

[Jeffrey B. <jef...@ea...>]

On Saturday 20 September 2008 18:55:17 Jeffrey Barish wrote:
> Configobj was working fine until I switched to using unrepr mode.  Now it
> works fine on one platform, but on another the same code produces the
> following error:
>
>   ...
>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1272, in
> __init__ self._load(infile, configspec)
>   File "/usr/lib/python2.5/site-packages/configobj.py", line 1355, in _load
>     raise error
> configobj.ConfigObjError: Parsing failed with several errors.
> First error at line 3.
>
> Line 3 is:
>
> v = 0.77304964539007093
>
> I am using version 4.5.3 on python 2.5.2.  Considering that the same rc
> file works fine on the other platform, I am at a loss as to what to do. 
> Any suggestions?

The problem appears to arise because there is no compiler module on this 
platform (Nokia N800).

Do I have any options other than returning to code like

if x == 'True'
-- 
Jeffrey Barish

[Configobj-develop] Problem with unrepr mode

[Jeffrey B. <jef...@ea...>]

Configobj was working fine until I switched to using unrepr mode.  Now it 
works fine on one platform, but on another the same code produces the 
following error:

  ...
  File "/usr/lib/python2.5/site-packages/configobj.py", line 1272, in __init__
    self._load(infile, configspec)
  File "/usr/lib/python2.5/site-packages/configobj.py", line 1355, in _load
    raise error
configobj.ConfigObjError: Parsing failed with several errors.
First error at line 3.

Line 3 is:

v = 0.77304964539007093

I am using version 4.5.3 on python 2.5.2.  Considering that the same rc file 
works fine on the other platform, I am at a loss as to what to do.  Any 
suggestions?
-- 
Jeffrey Barish

[Configobj-develop] [Fwd: ConfigObj and pickle bug]

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

Looks like we need to support pickle after all. *sigh*

-------- Original Message --------
Subject: 	ConfigObj and pickle bug
Date: 	Mon, 08 Sep 2008 10:30:26 +0200
From: 	Christian Heimes <c.h...@se...>
To: 	Michael Foord <fuz...@vo...>
CC: 	Dirk Rothe <d....@se...>



Dear Michael!

I run into some trouble when I used a ConfigObj object as an argument to 
parallel python. After some debugging I spotted a design issue in your code.

configobj.Section is a subclass of dict but it doesn't overwrite the 
pickle hook __reduce__. Pickling a section or configobj keeps the data 
in self (aka the dict) but not the data in self.__dict__. I came up with 
a quick hotfix for the problem.

# ---
import configobj
import copy_reg

def configobj_factory(cls):
    return cls.__new__(cls)

copy_reg.constructor(configobj_factory)

class SectionPatch(object):

    def __setstate__(self, state):
        dict.update(self, state[0])
        self.__dict__.update(state[1])

    def __reduce__(self):
        state = (dict(self), dict(self.__dict__))
        return (configobj_factory, (self.__class__, ), state)

def patch(cls, patchcls):
    bases = cls.__bases__
    if not patchcls in bases:
        cls.__bases__ = (patchcls,) + bases

patch(configobj.Section, SectionPatch)
# ---

Greeting
Christian


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.resolverhacks.net/
http://www.theotherdelia.co.uk/

Re: [Configobj-develop] Issues with nested Dict's and Lists

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

NICK VERBECK wrote:
> There seems to be a bug when trying to reconstruct a dictionary that
> contains a list. The first set of dictionary keys will parse out but
> the values just become the string repr of the rest of the
> dictionary/list.
>   

What code are you using to read / write the config?

Dictionaries in values will only be properly converted if you are using 
unrepr mode.

Michael

>
> Here is the saved string.
> clusters = "{'name': 'Default Cluster', 'servers': [{'ip':
> '127.0.0.1', 'name': 'Demo Server', 'port': '11211'}]}",
>
> This becomes
>
> config['cluster'] = "{'name': 'Default Cluster', 'servers': [{'ip':
> '127.0.0.1', 'name': 'Demo Server', 'port': '11211'}]}"
>
> This initial def was this
>
> config['clusters'] = [
>    {
>       'name': 'Default Cluster',
>       'servers': [
>          {
>             'ip': '127.0.0.1',
>             'name': Demo Server',
>             'port': '11211'
>          }
>       ]
>    }
> ]
>
> Hopefully that makes since.
>
>
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

[Configobj-develop] Issues with nested Dict's and Lists

[NICK V. <ner...@gm...>]

There seems to be a bug when trying to reconstruct a dictionary that
contains a list. The first set of dictionary keys will parse out but
the values just become the string repr of the rest of the
dictionary/list.


Here is the saved string.
clusters = "{'name': 'Default Cluster', 'servers': [{'ip':
'127.0.0.1', 'name': 'Demo Server', 'port': '11211'}]}",

This becomes

config['cluster'] = "{'name': 'Default Cluster', 'servers': [{'ip':
'127.0.0.1', 'name': 'Demo Server', 'port': '11211'}]}"

This initial def was this

config['clusters'] = [
   {
      'name': 'Default Cluster',
      'servers': [
         {
            'ip': '127.0.0.1',
            'name': Demo Server',
            'port': '11211'
         }
      ]
   }
]

Hopefully that makes since.


-- 
Nick Verbeck - NerdyNick
----------------------------------------------------
NerdyNick.com
VivaLaOpenSource.com
Coloco.ubuntu-rocks.org