Re: [Configobj-develop] List handling in Validator

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

On 03/01/2011 14:41, Stefan Parviainen wrote:
> On Mon, Jan 3, 2011 at 3:37 PM, Michael Foord<fuz...@vo...>  wrote:
>>> This would also solve problems with inconsistent naming (integer vs.
>>> int_list types). The old types could be kept for backwards compatibility.
>> This sounds like a good change.
> I can take a stab at it myself if you are busy/not interested in doing
> it yourself.
>

Tested patch with documentation stands a much better chance of making it 
into a release than leaving it to me... :-)

>> Note that in issue 26 values will *already* have been converted to lists if
>> they are in list format - so doing an *additional* split on ',' is
>> incorrect. For example this single string does *not* represent a list:
>>
>>     value = "something, with, commas"
> Well, I think that string does represent a list :-) And so does
> ConfigObj in some cases. Consider the following:
>
> import configobj, validate
> spec_str = """
> a = list
> b = integer
> """
> conf_str = """
> a = 1, 2
> b = 0
> """
> spec = configobj.ConfigObj(spec_str.split('\n'))
> conf = configobj.ConfigObj(conf_str.split('\n'), configspec=spec)
>
> conf.validate(validate.Validator())
>
> print type(conf['a']), conf['a']
> print type(conf['b']), conf['b']
>
> conf['a'] = '1, 2'
> conf['b'] = '0'
>
> res = conf.validate(validate.Validator())
>
> print type(conf['a']), conf['a']
> print type(conf['b']), conf['b']
>
> ---
> The above outputs:
> <type 'list'>  ['1', '2']
> <type 'int'>  0
> <type 'str'>  1, 2
> <type 'int'>  0
>
> So when parsing the config file "1,2" is indeed interpreted as a list,
No. 1,2 without quotes is a list. "1,2" with quotes is a string that 
happens to contain a comma.

The specified behaviour of ConfigObj and validate interaction is that 
list values should have already been parsed into a list *before* being 
validated - so the validation code must honour this. Otherwise, as I 
indicated, string values that contain commas can be incorrectly split 
into lists.


> but when "1,2" is assigned as a string it fails. Note that with the
> integer type, it succeeds in both cases. I expect that assigning a
> string with the same content as I would write in the config file would
> result in the same values after validation. It does not, which is
> confusing at least to me. I don't see a problem with splitting a
> string when it is assigned to something expecting a list. This is
> probably what the user wants anyway. Currently nothing sensible at all
> happens (you end up with a string where you are expecting a list!).
>
The list validation when a list is not supplied is not ideal - that is 
why I said your API suggestion was a good one. However quoted strings 
can contain commas that don't represent lists which is why your 
suggestion of always splitting on commas is bad.

> There is the force_list type, which kind of solves the problem (in a
> bad way IMHO), by converting the string to a list with a single item.
> But why is a string properly converted to an int, while a string is
> only converted to a list if force_list is used? Why is there no
> force_int?
What would be the use case of force_int? I don't really understand your 
point here.

> In summary: It is terribly confusing when I can't use the same syntax
> when assigning as I can when writing config files.
>
This is a different issue though. A ConfigObj instance will have 
*already* parsed list values. If you want a list value then assign a 
list. (Note that if you assign a value to the string "1,2" (without the 
quotes in the string itself) then ConfigObj will put quotes round it 
when it writes so that it is *not* read back in as a list.

Alternatively, it sounds like a reasonable feature request to ask for a 
method to parse a string using the ConfigObj syntax rules - so that you 
can use ConfigObj syntax for assigning strings.

All the best,

Michael Foord

-- 
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html