Re: [Configobj-develop] List handling in Validator

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

On 04/01/2011 14:18, Stefan Parviainen wrote:
> I see what the source of confusion might be. I am talking about values
> after validation has been performed. So when I say that I assign
> something and then the value is of type something I mean that it is
> after validation. Maybe this clears up some issues?
>
> On Mon, Jan 3, 2011 at 4:49 PM, Michael Foord<fuz...@vo...>  wrote:
>>> 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.
> My point is that I can do foo = 1,2  in a config file and it works
> correctly, but if I do config["foo"] = '1,2' it does not work. I would
> fully understand that "foo = '1,2'" and config["foo"] = "'1,2'" would
> not work (Notice the quotes inside the quotes). I think it's confusing
> that I can write one thing in a file, but not the exact same thing in
> the source. In this case I assign 1,2 (n.b. without any quotes) in
> both cases.

ConfigObj instance contain *parsed values*. If you want lists you must 
assign lists. Otherwise you would have to do your own quoting of any 
strings you assigned to a configobj instance yourself (including 
honouring the comment rules) just to allow you to assign lists as strings.

I suggested a "ConfigObj.parse(value)" API to allow you to do that though.
>> Otherwise, as I indicated, string values that contain commas can be incorrectly split into lists.
> Can you name a situation when splitting a string when something
> expects a list would lead to unwanted results? Not splitting the
> string, and instead assigning it directly _always_ leads to incorrect
> results when a list is expected.
>

I gave examples:

     value = "some value, that contains, commas"

>> However quoted strings can contain commas that don't represent lists
>> which is why your suggestion of always splitting on commas is bad.
> I'm certainly not suggesting that a string containing commas is
> _always_ interpreted as a list. Only when a list is expected!
> Maybe there is an error in my code, and it is always split, but that
> is certainly not the intention.
If a single value is passed and it contains commas your code would 
always split it which is incorrect. See example above.

>> What would be the use case of force_int? I don't really understand your
>> point here.
> Assigning a string to something expecting an integer "just works".
> Assigning a string to something expecting a list does not, instead
> force_list is needed. Don't you see the inconsistent behavior? I don't
> see why integers can be converted automatically (when needed) but
> lists require a separate type for this to work.

I did say that I *agreed* that the list handling was not ideal and even 
tentatively approved your api suggestions - minus the bug with respect 
to splitting strings into lists.

>>   If you want a list value then assign a list.
> I could similarly say that if you want an int value then assign an
> int.

Yep, that works. ;-)

>   Yet integer conversion from a string happens automatically. Why
> does not list conversion happen?
>

You seem to want to assign unparsed values *after* validation. What is 
your use case for this? (Why *not* just assign the correct values, why 
rely on ConfigObj to parse again?)

This is a slightly irrelevant question as I have agreed that list 
handling can be improved and suggested an API for parsing strings to 
lists where you want to assign them. I'm still *interested* in why you 
want to do this though.

>> 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.
> I think that an assignment should work the same, regardless if it's in
> a config file or in the source code.
>

It *isn't* the same though. A ConfigObj instance holds parsed (and 
possibly validated) values so you can't assign unparsed values and 
expect them to behave the same. How should ConfigObj know whether 
"config['foo'] = '1,2'" is a parsed or unparsed value being assigned? As 
I said earlier (we're just going over the same point again and again) if 
configobj behaved like this you would have to apply all the quoting 
rules manually instead of having configobj do it for you. Worse though: 
when parsing should configobj unquote values for you or not? If it does 
then "config['foo'] = config['foo']" could change the value when writing 
out! (A value quoted in the source would be unquoted when parsed - and 
if unquoted when assigned it would be written out unquoted.)

Either configobj would need to track all this state (which values have 
been parsed and which not) - with the "bug" above that assigning a value 
to itself could change it - or it would have to do no quoting and no 
unquoting. Nasty.

I don't think you really understand the consequences of what you're 
asking for. :-) Anyway, not gonna happen as you request. I would be open 
to patches implementing a "parse" method that allows you to do what you 
want though.

All the best,

Michael

> Once again:
> Assume the spec:
> p = list()
>
> Case 1, Conf file:
> p = 1,2
>
> Case 2, in source:
> config['p'] = '1,2'
>
> In both cases the right-hand side is: 1,2. The quotation marks in case
> 2 is there because of Python syntax. I am still assigning the value
> 1,2 without any quotes, just like in case 1.
>
> Given the above spec, in both cases, after validation, I expect p to
> be the list ['1','2']. Currently case 1 gives ['1','2'] while case 2
> gives a validation error. I don't think it makes sense to get
> different results given that the right-hand side is the same in both
> cases.
>


-- 
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