configobj-develop

[Configobj-develop] problems with non standard types like, wx.Colour

[Stef M. <s.m...@ru...>]

hello,

I'm using ConfigObj for writing/reading inifiles for a couple of months.
Until now I did a number of conversions myself,
but now I discovered a number of switches,
which in general do it much better than my own program (no wonder ;-)
These are my switches

    list_values = True,
    write_empty_values = True,
    unrepr = True )

It looks really good, even for complex nested structures.
But I've a few problems with non-standard types, like wx.Colour,
which is basically a tupple with some constraints.
In writing, ConfigObj writes: 

CS_SN1 = [wx.Colour(224, 224, 224, 255),  True, True, True, False]

that seems great, but ...
... I get an error if ConfigObj tries to read it back.

So I made a workaround, which works ok:

  def Write (self, name, value):
    if type(value) in [bool,int,str,float,list,tuple] :
      self[self.Section][name.strip()] = value
    else :
      try :
        # try to convert to tupple,
        # something like a wx.Colour can not be read back,
        # but can just as well be written/read as a tupple
        value = tuple ( value )
        self[self.Section][name.strip()] = value
      except :
        self[self.Section][name.strip()] = str(value)
    self.Modified = True

Why can't ConfigObj not read back wx.Colour (and others) ?
Any switches not set correct ?
And if it's not possible, is my workaround correct (btw doesn't work for 
nested non-standard types) ?

thanks,
Stef Mientki

Re: [Configobj-develop] [python] problems with non standard types like, wx.Colour

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

Stef Mientki wrote:
> hello,
>
> I'm using ConfigObj for writing/reading inifiles for a couple of months.
> Until now I did a number of conversions myself,
> but now I discovered a number of switches,
> which in general do it much better than my own program (no wonder ;-)
> These are my switches
>
>     list_values = True,
>     write_empty_values = True,
>     unrepr = True )
>   
Looks good - except I can't remember how list values interact with 
unrepr (I don't use unrepr mode myself and I implemented for Turbogears 
- in fact Kevin Dangoor contributed the code I think). On the other hand 
if it is *working* for you then it must be fine...

> It looks really good, even for complex nested structures.
> But I've a few problems with non-standard types, like wx.Colour,
> which is basically a tupple with some constraints.
> In writing, ConfigObj writes: 
>
> CS_SN1 = [wx.Colour(224, 224, 224, 255),  True, True, True, False]
>
> that seems great, but ...
> ... I get an error if ConfigObj tries to read it back.
>
> So I made a workaround, which works ok:
>
>   def Write (self, name, value):
>     if type(value) in [bool,int,str,float,list,tuple] :
>       self[self.Section][name.strip()] = value
>     else :
>       try :
>         # try to convert to tupple,
>         # something like a wx.Colour can not be read back,
>         # but can just as well be written/read as a tupple
>         value = tuple ( value )
>         self[self.Section][name.strip()] = value
>       except :
>         self[self.Section][name.strip()] = str(value)
>     self.Modified = True
>
> Why can't ConfigObj not read back wx.Colour (and others) ?
> Any switches not set correct ?
> And if it's not possible, is my workaround correct (btw doesn't work for 
> nested non-standard types) ?
>   

ConfigObj is not *intended* to read in (or write out) non-standard types 
in unrepr mode. A way of extending unrepr mode for this would be nice (a 
way of recognising non standard types and reprs in the read/write 
phases), but as I don't use unrepr mode it would have to be implemented 
by someone else. It shouldn't actually be very hard - the difficult part 
is deciding on a clean and simple API (a dictionary of names mapping to 
types - although 'wx.Color' might be a problem because unrepr uses the 
Python parser and that is a dotted name rather than just a name).

Your fix - to write the value out as a tuple if it can be converted is 
clever, but in general it might not 'do the right thing' when read back 
in.  (For users who aren't aware of this behaviour.) In general I prefer 
to raise an exception than do clever tricks.

For handling custom types you can use 'validate.py' and configspecs, but 
off the top of my head I don't think that they work well with unrepr mode.

How about using the walk method to recursively change wx.Colour objects 
into tuples before writing?

Michael

> thanks,
> Stef Mientki
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>   

Re: [Configobj-develop] [python] problems with non standard types like, wx.Colour

[Stef M. <s.m...@ru...>]

hello Michael,

Michael Foord wrote:
> Stef Mientki wrote:
>   
>> hello,
>>
>> I'm using ConfigObj for writing/reading inifiles for a couple of months.
>> Until now I did a number of conversions myself,
>> but now I discovered a number of switches,
>> which in general do it much better than my own program (no wonder ;-)
>> These are my switches
>>
>>     list_values = True,
>>     write_empty_values = True,
>>     unrepr = True )
>>   
>>     
> Looks good - except I can't remember how list values interact with 
> unrepr (I don't use unrepr mode myself and I implemented for Turbogears 
> - in fact Kevin Dangoor contributed the code I think). On the other hand 
> if it is *working* for you then it must be fine...
>   
For what I've tested (just trial and error), unrepr, can handle a lot 
more complex structures:
e.g. with "unrepr=False", writing
  [[1, 2, 3, 4, 5], (1, 2), [1, (2, 3), [6]]]
result is reading:
   ['[1, 2, 3, 4, 5]', '(1, 2)', '[1, (2, 3), [6]]']
while "unrepr=True", it reads back exactly how it was written.

>   
>> It looks really good, even for complex nested structures.
>> But I've a few problems with non-standard types, like wx.Colour,
>> which is basically a tupple with some constraints.
>> In writing, ConfigObj writes: 
>>
>> CS_SN1 = [wx.Colour(224, 224, 224, 255),  True, True, True, False]
>>
>> that seems great, but ...
>> ... I get an error if ConfigObj tries to read it back.
>>
>> So I made a workaround, which works ok:
>>
>>   def Write (self, name, value):
>>     if type(value) in [bool,int,str,float,list,tuple] :
>>       self[self.Section][name.strip()] = value
>>     else :
>>       try :
>>         # try to convert to tupple,
>>         # something like a wx.Colour can not be read back,
>>         # but can just as well be written/read as a tupple
>>         value = tuple ( value )
>>         self[self.Section][name.strip()] = value
>>       except :
>>         self[self.Section][name.strip()] = str(value)
>>     self.Modified = True
>>
>> Why can't ConfigObj not read back wx.Colour (and others) ?
>> Any switches not set correct ?
>> And if it's not possible, is my workaround correct (btw doesn't work for 
>> nested non-standard types) ?
>>   
>>     
>
> ConfigObj is not *intended* to read in (or write out) non-standard types 
> in unrepr mode. A way of extending unrepr mode for this would be nice (a 
> way of recognising non standard types and reprs in the read/write 
> phases), but as I don't use unrepr mode it would have to be implemented 
> by someone else. It shouldn't actually be very hard - the difficult part 
> is deciding on a clean and simple API (a dictionary of names mapping to 
> types - although 'wx.Color' might be a problem because unrepr uses the 
> Python parser and that is a dotted name rather than just a name).
>
> Your fix - to write the value out as a tuple if it can be converted is 
> clever, but in general it might not 'do the right thing' when read back 
> in.  (For users who aren't aware of this behaviour.) In general I prefer 
> to raise an exception than do clever tricks.
>
> For handling custom types you can use 'validate.py' and configspecs, but 
> off the top of my head I don't think that they work well with unrepr mode.
>
>   
Ok, that's all too complex for me (at least for now).
As I want to store fairly complex structures, with a lot of special classes,
I'm also not sure if this really solves everything.
> How about using the walk method to recursively change wx.Colour objects 
> into tuples before writing?
>   
never heard of walk, again too complex for now ;-)

So thanks again,
I'm glad to know that the work around I use is not completely nonsense !

cheers,
Stef Mientki

Re: [Configobj-develop] [python] problems with non standard types like, wx.Colour

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

Stef Mientki wrote:
> [snip...]
>> ConfigObj is not *intended* to read in (or write out) non-standard types 
>> in unrepr mode. A way of extending unrepr mode for this would be nice (a 
>> way of recognising non standard types and reprs in the read/write 
>> phases), but as I don't use unrepr mode it would have to be implemented 
>> by someone else. It shouldn't actually be very hard - the difficult part 
>> is deciding on a clean and simple API (a dictionary of names mapping to 
>> types - although 'wx.Color' might be a problem because unrepr uses the 
>> Python parser and that is a dotted name rather than just a name).
>>
>> Your fix - to write the value out as a tuple if it can be converted is 
>> clever, but in general it might not 'do the right thing' when read back 
>> in.  (For users who aren't aware of this behaviour.) In general I prefer 
>> to raise an exception than do clever tricks.
>>
>> For handling custom types you can use 'validate.py' and configspecs, but 
>> off the top of my head I don't think that they work well with unrepr mode.
>>
>>   
>>     
> Ok, that's all too complex for me (at least for now).
> As I want to store fairly complex structures, with a lot of special classes,
> I'm also not sure if this really solves everything.
>   

Right.
>> How about using the walk method to recursively change wx.Colour objects 
>> into tuples before writing?
>>   
>>     
> never heard of walk, again too complex for now ;-)
>   

Walk is just a recursive method for calling a function on all the 
members in a config. It is documented and probably underused. :-)

Michael
> So thanks again,
> I'm glad to know that the work around I use is not completely nonsense !
>
> cheers,
> Stef Mientki
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>