configobj-develop — Support and development of ConfigObj

Re: [Configobj-develop] newbie error

[Chris S. <so...@st...>]

Hi Anton,

I'm using an older version of ConfigObj, but your file works for me - only after I get rid of the duplicate 'soc_source' line (I'm not sure how you got past the initial load):

> >>> co = configobj.ConfigObj('newbie.cfg')
> >>> co
> ConfigObj({'retail_price': '$400', 'soc_source': '1', 'soc_theme': '2', 'soc_target': '3', 'soc_folder_exist': '4', 'soc_folder_temp_exist': '5', 'soc_folder_backup_exist': '6', 'som_somserver': '1', 'som_filename': '2', 'som_sourcefile': '3', 'som_targetfile': '4', 'som_fileexist': '5', 'som_file_temp_exist': '6', 'som_file_backup_exist': '7'})
> >>> co["som_somserver"]
> '1'

Chris


On 2/24/11 8:50 AM, Anton Hughes wrote:
> Hi
> Im trying to use ConfigObj but am getting the following error. And I have know idea what I am doing wrong. Anyone can help?
>
> from configobj import ConfigObj
> config = ConfigObj('c:\temp\config.ini')
> config["som_somserver"]
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "build\bdist.win32\egg\configobj.py", line 567, in __getitem__
>     val = dict.__getitem__(self, key)
> KeyError: 'som_somserver'
>
>
>
> Here is a copy of my config file:
> soc_source = soc_source
> retail_price = $400
> soc_source = 1
> soc_theme = 2
> soc_target = 3
> soc_folder_exist = 4
> soc_folder_temp_exist = 5
> soc_folder_backup_exist = 6
> som_somserver = 1
> som_filename=2
> som_sourcefile = 3
> som_targetfile = 4
> som_fileexist = 5
> som_file_temp_exist=6
> som_file_backup_exist=7
>
> Thanks
>

Re: [Configobj-develop] newbie error

[David H. <neg...@gm...>]

Ha!  Good catch.

Yeah, he's ending up with a cfg that has the following:

>>> cfg.filename
'c:\temp\\config.ini'
>>> cfg.dict()
{}
>>>

Thus... an empty data set because it never opened any existing file for parsing.

And as soon as he fixes that, he'll get the following:

configobj.configobj.DuplicateError: Duplicate keyword name at line 3.


cheers,

-hoss




On Thu, Feb 24, 2011 at 08:53, Michael Foord <fuz...@vo...> wrote:
> On 24/02/2011 13:50, Anton Hughes wrote:
>
> Hi
> Im trying to use ConfigObj but am getting the following error. And I have
> know idea what I am doing wrong. Anyone can help?
>
> from configobj import ConfigObj
> config = ConfigObj('c:\temp\config.ini')
>
> This line probably doesn't do what you expect. In Python the backslash is an
> escape character in strings and "\t" is a tab. Try this instead:
>
>     config = ConfigObj(r'c:\temp\config.ini')
>
> The "r" makes the string raw so that backslashes are literals rather than
> escape characters.
>
> All the best,
>
> Michael Foord
>
> config["som_somserver"]
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "build\bdist.win32\egg\configobj.py", line 567, in __getitem__
>     val = dict.__getitem__(self, key)
> KeyError: 'som_somserver'
>
>
> Here is a copy of my config file:
> soc_source = soc_source
> retail_price = $400
> soc_source = 1
> soc_theme = 2
> soc_target = 3
> soc_folder_exist = 4
> soc_folder_temp_exist = 5
> soc_folder_backup_exist = 6
> som_somserver = 1
> som_filename=2
> som_sourcefile = 3
> som_targetfile = 4
> som_fileexist = 5
> som_file_temp_exist=6
> som_file_backup_exist=7
> Thanks
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>
> --
> 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
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>

Re: [Configobj-develop] newbie error

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

On 24/02/2011 13:50, Anton Hughes wrote:
> Hi
> Im trying to use ConfigObj but am getting the following error. And I 
> have know idea what I am doing wrong. Anyone can help?
>
> from configobj import ConfigObj
> config = ConfigObj('c:\temp\config.ini')

This line probably doesn't do what you expect. In Python the backslash 
is an escape character in strings and "\t" is a tab. Try this instead:

     config = ConfigObj(r'c:\temp\config.ini')

The "r" makes the string raw so that backslashes are literals rather 
than escape characters.

All the best,

Michael Foord
> config["som_somserver"]
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "build\bdist.win32\egg\configobj.py", line 567, in __getitem__
>     val = dict.__getitem__(self, key)
> KeyError: 'som_somserver'
>
>
>
> Here is a copy of my config file:
> soc_source = soc_source
> retail_price = $400
> soc_source = 1
> soc_theme = 2
> soc_target = 3
> soc_folder_exist = 4
> soc_folder_temp_exist = 5
> soc_folder_backup_exist = 6
> som_somserver = 1
> som_filename=2
> som_sourcefile = 3
> som_targetfile = 4
> som_fileexist = 5
> som_file_temp_exist=6
> som_file_backup_exist=7
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
>
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop


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

Re: [Configobj-develop] newbie error

[David H. <neg...@gm...>]

For starters, make sure you're actually referring to the config.ini
file that you think you are, and that it contains what you intend it
to contain.

The one you provided doesn't even parse correctly because it's got
'soc_source' listed as a keyword twice.  So the example code you have
doesn't even match the example file, since the following line would
throw an exception:

> config = ConfigObj('c:\temp\config.ini')

Which leads me to suspect that perhaps the config.ini file that you're
actually loading does NOT, in fact, have the following line in it:

> som_somserver = 1


Which would explain the KeyError.


cheers,

-hoss





On Thu, Feb 24, 2011 at 08:50, Anton Hughes <kur...@gm...> wrote:
> Hi
> Im trying to use ConfigObj but am getting the following error. And I have
> know idea what I am doing wrong. Anyone can help?
>
> from configobj import ConfigObj
> config = ConfigObj('c:\temp\config.ini')
> config["som_somserver"]
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "build\bdist.win32\egg\configobj.py", line 567, in __getitem__
>     val = dict.__getitem__(self, key)
> KeyError: 'som_somserver'
>
>
> Here is a copy of my config file:
> soc_source = soc_source
> retail_price = $400
> soc_source = 1
> soc_theme = 2
> soc_target = 3
> soc_folder_exist = 4
> soc_folder_temp_exist = 5
> soc_folder_backup_exist = 6
> som_somserver = 1
> som_filename=2
> som_sourcefile = 3
> som_targetfile = 4
> som_fileexist = 5
> som_file_temp_exist=6
> som_file_backup_exist=7
> Thanks
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>

[Configobj-develop] newbie error

[Anton H. <kur...@gm...>]

Hi
Im trying to use ConfigObj but am getting the following error. And I have
know idea what I am doing wrong. Anyone can help?

from configobj import ConfigObj
config = ConfigObj('c:\temp\config.ini')
config["som_somserver"]
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "build\bdist.win32\egg\configobj.py", line 567, in __getitem__
    val = dict.__getitem__(self, key)
KeyError: 'som_somserver'



Here is a copy of my config file:
soc_source = soc_source
retail_price = $400
soc_source = 1
soc_theme = 2
soc_target = 3
soc_folder_exist = 4
soc_folder_temp_exist = 5
soc_folder_backup_exist = 6
som_somserver = 1
som_filename=2
som_sourcefile = 3
som_targetfile = 4
som_fileexist = 5
som_file_temp_exist=6
som_file_backup_exist=7

Thanks

Re: [Configobj-develop] Arbitrary depth

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

On 10/01/2011 05:02, Entity Reborn wrote:
> Quick question, does the validation regime support children of 
> arbitrary depth?
> For example:
>
> [root]
> ...
>     [[child1]]
>     ....
>         [[[child2]]]]
>         ....
>             ....
>                 [[[[[[[childx]]]]]]]
>
> In my program, all children are of the same classtype, will support 
> the same options.
>

Hello,

Sorry for the late reply. This is not supported out of the box I'm 
afraid. You could roll it yourself with the validate module though.

All the best,

Michael

> -- 
> ~EntityReborn
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
>
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop


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

[Configobj-develop] Arbitrary depth

[Entity R. <ent...@gm...>]

Quick question, does the validation regime support children of arbitrary
depth?
For example:

[root]
...
    [[child1]]
    ....
        [[[child2]]]]
        ....
            ....
                [[[[[[[childx]]]]]]]

In my program, all children are of the same classtype, will support the same
options.

-- 
~EntityReborn

Re: [Configobj-develop] Improved list syntax

[David H. <neg...@gm...>]

On Thu, Jan 6, 2011 at 09:22, Whitaker, Maria - BLS <Whi...@bl...> wrote:
> Can you take my name off the mailing list?  Thanks.

No, but you can:

https://lists.sourceforge.net/lists/listinfo/configobj-develop

(the info is in the footer of every email sent to the list)

cheers,

-David

Re: [Configobj-develop] Improved list syntax

[Whitaker, M. - B. <Whi...@BL...>]

Can you take my name off the mailing list?  Thanks.

Maria Whitaker


-----Original Message-----
From: Michael Foord [mailto:fuz...@vo...] 
Sent: Thursday, January 06, 2011 7:23 AM
To: con...@li...
Subject: Re: [Configobj-develop] Improved list syntax

On 05/01/2011 18:48, Stefan Parviainen wrote:
> On Wed, Jan 5, 2011 at 8:28 PM, Michael Foord<fuz...@vo...>
wrote:
>>> I created a clone of ConfigObj on Google Code
>>> (http://code.google.com/r/pafcu-configobj/) where I will put any 
>>> fixes and improvements to ConfigObj and Validator that I can come up
with.
>> Cool. When you're happy with what you've done could you create an 
>> issue on the configobj issue tracker and attach a patch please.
> Personally I prefer the distributed workflow most projects seem to be 
> switching to:
> "Because mercurial is a distributed (peer-to-peer) version control 
> system, it excels at branching and merging. If the project maintainers 
> like the new code, they just "pull" the changesets from the clone and 
> merge them into an official project repository. It's all much more 
> elegant than emailing patches back and forth, anonymous contributors 
> get to use the same tools as core developers." (From the Google Code 
> Docs). But I guess patches to the issue tracker is OK too.
>
> I'm pretty happy with the lists now (it was a pretty minor thing to
> fix) and I also fixed issues #20, #24, #25, and #27 (added tests for 
> these + fixed some of the old tests). I'll see when I have time to put 
> together some patches. In the meantime anyone who wants to test this 
> can just pull the changes from my repository.
>
Ok, I can pull the changes from your repo instead of needing patches. 
Can you add a note to the relevant issues with the project / repo url. 
That will help when I come to look through the issues.

Many thanks,

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


----------------------------------------------------------------------------
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment,
and, should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Configobj-develop mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/configobj-develop

Re: [Configobj-develop] Improved list syntax

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

On 05/01/2011 18:48, Stefan Parviainen wrote:
> On Wed, Jan 5, 2011 at 8:28 PM, Michael Foord<fuz...@vo...>  wrote:
>>> I created a clone of ConfigObj on Google Code
>>> (http://code.google.com/r/pafcu-configobj/) where I will put any fixes
>>> and improvements to ConfigObj and Validator that I can come up with.
>> Cool. When you're happy with what you've done could you create an issue
>> on the configobj issue tracker and attach a patch please.
> Personally I prefer the distributed workflow most projects seem to be
> switching to:
> "Because mercurial is a distributed (peer-to-peer) version control
> system, it excels at branching and merging. If the project maintainers
> like the new code, they just "pull" the changesets from the clone and
> merge them into an official project repository. It's all much more
> elegant than emailing patches back and forth, anonymous contributors
> get to use the same tools as core developers." (From the Google Code
> Docs). But I guess patches to the issue tracker is OK too.
>
> I'm pretty happy with the lists now (it was a pretty minor thing to
> fix) and I also fixed issues #20, #24, #25, and #27 (added tests for
> these + fixed some of the old tests). I'll see when I have time to put
> together some patches. In the meantime anyone who wants to test this
> can just pull the changes from my repository.
>
Ok, I can pull the changes from your repo instead of needing patches. 
Can you add a note to the relevant issues with the project / repo url. 
That will help when I come to look through the issues.

Many thanks,

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

Re: [Configobj-develop] Improved list syntax

[Stefan P. <pa...@ik...>]

On Wed, Jan 5, 2011 at 8:28 PM, Michael Foord <fuz...@vo...> wrote:
>> I created a clone of ConfigObj on Google Code
>> (http://code.google.com/r/pafcu-configobj/) where I will put any fixes
>> and improvements to ConfigObj and Validator that I can come up with.
> Cool. When you're happy with what you've done could you create an issue
> on the configobj issue tracker and attach a patch please.

Personally I prefer the distributed workflow most projects seem to be
switching to:
"Because mercurial is a distributed (peer-to-peer) version control
system, it excels at branching and merging. If the project maintainers
like the new code, they just "pull" the changesets from the clone and
merge them into an official project repository. It's all much more
elegant than emailing patches back and forth, anonymous contributors
get to use the same tools as core developers." (From the Google Code
Docs). But I guess patches to the issue tracker is OK too.

I'm pretty happy with the lists now (it was a pretty minor thing to
fix) and I also fixed issues #20, #24, #25, and #27 (added tests for
these + fixed some of the old tests). I'll see when I have time to put
together some patches. In the meantime anyone who wants to test this
can just pull the changes from my repository.

-- 
Stefan Parviainen

Re: [Configobj-develop] Improved list syntax

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

On 05/01/2011 14:26, Stefan Parviainen wrote:
> Hi all,
>
> I created a clone of ConfigObj on Google Code
> (http://code.google.com/r/pafcu-configobj/) where I will put any fixes
> and improvements to ConfigObj and Validator that I can come up with.
> Right now the only thing I have added is an improved list syntax
> allowing you to specify what type list members should have. You can
> also specify whether a tuple or list should be used.
>
Cool. When you're happy with what you've done could you create an issue 
on the configobj issue tracker and attach a patch please.

https://code.google.com/p/configobj/issues/list

All the best,

Michael Foord

> Now you can e.g. define a tuple containing ints between 1 and 10 by doing
>
> mylist = list(type="integer(min=1, max=10)", is_tuple=True)
>
> This should also work for custom types.
>
> In theory we could now get rid of all the XXX_list types, but for
> backwards compatibility I have left them in for now. They are a
> convinient short-hand notation, but at the very lest they should be
> renamed so they match their corresponding non-list type (e.g. rename
> int_list ->  integer_list OR integer ->  int). I also left in the
> top-level is_list() and is_tuple() functions which have the old
> behaviour for backwards compatibility.
>
> Old tests are passed and I added some new ones to check that the new
> syntax also works as expected.
>


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

Re: [Configobj-develop] On the included tests

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

On 05/01/2011 17:15, David Hostetler wrote:
>> I came to hate doctests more and more and I write new tests as unit
>> tests.
> Yay!!!  :)
>
>
>> The tests that were left in the source code of configobj.py are only
>> ones I thought were useful as "documentation" in the docstrings. It is
>> possible that some of those should be deleted if they're duplicated in
>> the test file and are a maintenance burden.
> If you're no longer running doctests or encouraging others to, then if
> the stuff still in the source remains valuable from a reference/usage
> point of view it should probably at least be made to not look like
> doctests, and just appear as straight-up inline documentation.

Well - actually the *only* good use of doctests is to make examples 
executable (and therefore signal if the example break). If the tests 
currently inline can be made to look better whilst retaining testability 
then I'd be open to that change.


> Otherwise people familiar with the format will think they're
> legitimately active tests and probably will adopt a 'when in rome'
> approach.  If they're only of marginal doc value then I think they
> could be stripped out altogether.  Both configobj and validate are
> well documented and that allows cleanliness and maintainability of the
> source code to have higher priority.
>
Ones that are of marginal doc value can definitely be stripped out.


Michael

> regards,
>
> -hoss
>
> David Hostetler
> neg...@gm...
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop


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

Re: [Configobj-develop] On the included tests

[David H. <neg...@gm...>]

> I came to hate doctests more and more and I write new tests as unit
> tests.

Yay!!!  :)


> The tests that were left in the source code of configobj.py are only
> ones I thought were useful as "documentation" in the docstrings. It is
> possible that some of those should be deleted if they're duplicated in
> the test file and are a maintenance burden.

If you're no longer running doctests or encouraging others to, then if
the stuff still in the source remains valuable from a reference/usage
point of view it should probably at least be made to not look like
doctests, and just appear as straight-up inline documentation.
Otherwise people familiar with the format will think they're
legitimately active tests and probably will adopt a 'when in rome'
approach.  If they're only of marginal doc value then I think they
could be stripped out altogether.  Both configobj and validate are
well documented and that allows cleanliness and maintainability of the
source code to have higher priority.


regards,

-hoss

David Hostetler
neg...@gm...

Re: [Configobj-develop] On the included tests

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

On 05/01/2011 16:38, Stefan Parviainen wrote:
> Hi,
>
> I was requested to include tests together with any patches I might
> make. After looking at the included tests I have to say that I'm a bit
> confused as to where and how the tests should be included. It seems
> like there are some doctests in the main source files, configobj.py
> and validate.py. Mostly similar, yet different tests can be found in
> test_configobj.py. Yet more tests can be found in the functionaltests
> subdirectory.
>
> Currently some tests are failing on Python 2.7 due to how the tests
> are written. Instead of fixing the same doctest bugs in 2 or 3
> different places, would it be better to take some time and consolidate
> all the different tests in one place? Where should the test be stored?
> Personally I prefer to store tests outside the main source code
> because I find it cleaner, but others might disagree.
>
Hey Stefan,

Short answer - best to add new tests as unit tests rather than doctests 
and patches to fix existing failures on 2.7 are appreciated but probably 
best done separately.

ConfigObj and validate were originally tested by doctests in the source 
code only. This got unwieldy (i.e. horrible) and most of the doctests 
were moved out of the configobj source and into their own file. Over 
time I came to hate doctests more and more and I write new tests as unit 
tests.

The tests that were left in the source code of configobj.py are only 
ones I thought were useful as "documentation" in the docstrings. It is 
possible that some of those should be deleted if they're duplicated in 
the test file and are a maintenance burden.

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

[Configobj-develop] On the included tests

[Stefan P. <pa...@ik...>]

Hi,

I was requested to include tests together with any patches I might
make. After looking at the included tests I have to say that I'm a bit
confused as to where and how the tests should be included. It seems
like there are some doctests in the main source files, configobj.py
and validate.py. Mostly similar, yet different tests can be found in
test_configobj.py. Yet more tests can be found in the functionaltests
subdirectory.

Currently some tests are failing on Python 2.7 due to how the tests
are written. Instead of fixing the same doctest bugs in 2 or 3
different places, would it be better to take some time and consolidate
all the different tests in one place? Where should the test be stored?
Personally I prefer to store tests outside the main source code
because I find it cleaner, but others might disagree.

-- 
Stefan Parviainen

[Configobj-develop] Improved list syntax

[Stefan P. <sap...@gm...>]

Hi all,

I created a clone of ConfigObj on Google Code
(http://code.google.com/r/pafcu-configobj/) where I will put any fixes
and improvements to ConfigObj and Validator that I can come up with.
Right now the only thing I have added is an improved list syntax
allowing you to specify what type list members should have. You can
also specify whether a tuple or list should be used.

Now you can e.g. define a tuple containing ints between 1 and 10 by doing

mylist = list(type="integer(min=1, max=10)", is_tuple=True)

This should also work for custom types.

In theory we could now get rid of all the XXX_list types, but for
backwards compatibility I have left them in for now. They are a
convinient short-hand notation, but at the very lest they should be
renamed so they match their corresponding non-list type (e.g. rename
int_list -> integer_list OR integer -> int). I also left in the
top-level is_list() and is_tuple() functions which have the old
behaviour for backwards compatibility.

Old tests are passed and I added some new ones to check that the new
syntax also works as expected.

-- 
Stefan Parviainen

Re: [Configobj-develop] List handling in Validator

[Stefan P. <pa...@ik...>]

On Tue, Jan 4, 2011 at 9:05 PM, Entity Reborn <ent...@gm...> wrote:
> Wouldn't you mean:
> conf['mylist'] = [1,2,3]
> Otherwise you are feeding the object a string.
If I meant that my entire post would make no sense :-) Yes, I would be
feeding it a string. Some say it shouldn't work that way. Fair enough,
I can accept that feeding a string to something not expecting a string
should produce an error. But why doesn't conf['myint'] = '1' produce
an error? I'm feeding it too a string. Why can I feed a string in one
case but not the other when in neither case a string is what is
expected. What I'm feeding is wrong in both cases: in one case
implicit conversion occurs, in the other it doesn't.

(This post is just to clarify my previous message, as promised I
stopped arguing my point :-)

-- 
Stefan Parviainen

Re: [Configobj-develop] List handling in Validator

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

On 04/01/2011 19:01, Stefan Parviainen wrote:
> On Tue, Jan 4, 2011 at 5:03 PM, David Hostetler<neg...@gm...>  wrote:
>> config["foo"] = '1,2'  is Python code!!
> OK, it seems clear that my point is not getting across at all.
You have made your point you just don't seem to have understood the 
responses as to why it doesn't (and shouldn't) work like that. :-)

Michael


> It
> seems difficult to convey what I'm trying to say over the internet, so
> after this I'm giving up on this point, and will simply continue to
> use a workaround in my own program.
>
> Consider the spec:
> myint = integer
> mylist = list
>
> Assume conf is of type ConfigObj using the above mentioned spec.
>
> conf['myint'] = '1'
> conf[mylist'] = '1,2,3'
>
> After validation myint will be converter to integer while mylist will
> _not_ be converted to a list. I simply do not understand why one is
> converted but the other isn't. You may very well be right, and I'm
> wrong, and I see little point in continuing to argue about this weird
> behaviour, especially since there's a simple workaround that I already
> use in my programs.
>


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

Re: [Configobj-develop] List handling in Validator

[Entity R. <ent...@gm...>]

Wouldn't you mean:
conf['mylist'] = [1,2,3]
Otherwise you are feeding the object a string.

On Jan 4, 2011, at 11:01 AM, Stefan Parviainen <pa...@ik...> wrote:

> On Tue, Jan 4, 2011 at 5:03 PM, David Hostetler <neg...@gm...> wrote:
>> config["foo"] = '1,2'  is Python code!!
> OK, it seems clear that my point is not getting across at all. It
> seems difficult to convey what I'm trying to say over the internet, so
> after this I'm giving up on this point, and will simply continue to
> use a workaround in my own program.
>
> Consider the spec:
> myint = integer
> mylist = list
>
> Assume conf is of type ConfigObj using the above mentioned spec.
>
> conf['myint'] = '1'
> conf[mylist'] = '1,2,3'
>
> After validation myint will be converter to integer while mylist will
> _not_ be converted to a list. I simply do not understand why one is
> converted but the other isn't. You may very well be right, and I'm
> wrong, and I see little point in continuing to argue about this weird
> behaviour, especially since there's a simple workaround that I already
> use in my programs.
>
> --
> Stefan Parviainen
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop

Re: [Configobj-develop] List handling in Validator

[Stefan P. <pa...@ik...>]

On Tue, Jan 4, 2011 at 5:03 PM, David Hostetler <neg...@gm...> wrote:
> config["foo"] = '1,2'  is Python code!!
OK, it seems clear that my point is not getting across at all. It
seems difficult to convey what I'm trying to say over the internet, so
after this I'm giving up on this point, and will simply continue to
use a workaround in my own program.

Consider the spec:
myint = integer
mylist = list

Assume conf is of type ConfigObj using the above mentioned spec.

conf['myint'] = '1'
conf[mylist'] = '1,2,3'

After validation myint will be converter to integer while mylist will
_not_ be converted to a list. I simply do not understand why one is
converted but the other isn't. You may very well be right, and I'm
wrong, and I see little point in continuing to argue about this weird
behaviour, especially since there's a simple workaround that I already
use in my programs.

-- 
Stefan Parviainen

Re: [Configobj-develop] List handling in Validator

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

On 04/01/2011 15:03, David Hostetler wrote:
> Stefan, you're conflating the concepts of data format and programming 
> language syntax (i.e. code).
>

What you've said is true David.

Reading Stefan's mind (because he hasn't explained his use case) I 
imagine that he has data input from the user (or some other source) that 
he wants to treat in the same way as if it had been written in a config 
file. He is annoyed that just setting it on a ConfigObj instance doesn't 
do that.

For all the reasons both you and I have explained it isn't a good idea 
for it to work that way anyway...

However, given that he *may* have a reasonable use case for taking 
string data and then treating it as unparsed config data, I'd be happy 
with an API that *allows* him to do that without making it the default 
behaviour.

All the best,

Michael Foord

> The entire purpose of ConfigObj, and it's config file format, rules, 
> and API, is to allow data to successfully and robustly make the 
> transition _between_ a text-based file/storage format and program code.
>
> The purpose is NOT to muddy the distinction between data saved in a 
> storage format and the specification for literals in the Python data 
> model.
>
>     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.
>
>
> config["foo"] = '1,2'  is Python code!!   It works, and does precisely 
> what it should.  The specification for Python's lexical data model is 
> long-standing, proven, consistent, understood, and powerful.   And 
> you're proposing that ConfigObj should intentionally subvert it for 
> convenience!?
>
> A programmer should _never_ have to ask themselves, when typing out an 
> assignment in code, "oops... am I writing Python, or am I writing 
> ConfigObj?"   But that's exactly the kind of ambiguity your proposal 
> would be injecting.
>
> One of the most useful concepts a programmer can embrace is that of 
> establishing and respecting a very firm and distinct boundary between 
> stored data and programmatic data.  This is one of the 'tricks' of 
> successful i18n/L10n programming, but it's equally effective as a 
> general rule.
>
> With respect to ConfigObj use, applying that concept means respecting 
> the boundary between the config storage syntax and the ConfigObj API 
> in Python space.  Once a blob of stored config text has been digested 
> and converted into programmatic/Python variables, you're squarely in 
> Python land.  Write Python.  You should neither want nor expect any of 
> the various and sundry details of the storage format itself to intrude 
> upon your ability to exercise and rely upon the Python data model.
>
> In other words, once data has been processed and is in a ConfigObj 
> instance, a list is only ever list because it's a list.  type(x) == 
> types.ListType.   To violate that is to invite madness and anarchy. 
>  And note that the true Python connoisseur wouldn't be doing explicit 
> type checking anyway, they'd be duck-hunting.  :)
>
>
> cheers,
>
> -hoss
>
> David Hostetler
> neg...@gm... <mailto:neg...@gm...>
>
>
>
> On Tue, Jan 4, 2011 at 09:18, Stefan Parviainen <pa...@ik... 
> <mailto:pa...@ik...>> 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... <mailto: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.
>
>     > 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.
>
>     > 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.
>
>     > 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.
>
>     >  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. Yet integer conversion from a string happens automatically. Why
>     does not list conversion happen?
>
>     > 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.
>
>     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.
>
>     --
>     Stefan Parviainen
>
>     ------------------------------------------------------------------------------
>     Learn how Oracle Real Application Clusters (RAC) One Node allows
>     customers
>     to consolidate database storage, standardize their database
>     environment, and,
>     should the need arise, upgrade to a full multi-node Oracle RAC
>     database
>     without downtime or disruption
>     http://p.sf.net/sfu/oracle-sfdevnl
>     _______________________________________________
>     Configobj-develop mailing list
>     Con...@li...
>     <mailto:Con...@li...>
>     https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
>
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop


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

Re: [Configobj-develop] List handling in Validator

[David H. <neg...@gm...>]

Stefan, you're conflating the concepts of data format and programming
language syntax (i.e. code).

The entire purpose of ConfigObj, and it's config file format, rules, and
API, is to allow data to successfully and robustly make the transition
_between_ a text-based file/storage format and program code.

The purpose is NOT to muddy the distinction between data saved in a storage
format and the specification for literals in the Python data model.

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.


config["foo"] = '1,2'  is Python code!!   It works, and does precisely what
it should.  The specification for Python's lexical data model is
long-standing, proven, consistent, understood, and powerful.   And you're
proposing that ConfigObj should intentionally subvert it for convenience!?

A programmer should _never_ have to ask themselves, when typing out an
assignment in code, "oops... am I writing Python, or am I writing
ConfigObj?"   But that's exactly the kind of ambiguity your proposal would
be injecting.

One of the most useful concepts a programmer can embrace is that of
establishing and respecting a very firm and distinct boundary between stored
data and programmatic data.  This is one of the 'tricks' of successful
i18n/L10n programming, but it's equally effective as a general rule.

With respect to ConfigObj use, applying that concept means respecting the
boundary between the config storage syntax and the ConfigObj API in Python
space.  Once a blob of stored config text has been digested and converted
into programmatic/Python variables, you're squarely in Python land.  Write
Python.  You should neither want nor expect any of the various and sundry
details of the storage format itself to intrude upon your ability to
exercise and rely upon the Python data model.

In other words, once data has been processed and is in a ConfigObj instance,
a list is only ever list because it's a list.  type(x) == types.ListType.
To violate that is to invite madness and anarchy.  And note that the true
Python connoisseur wouldn't be doing explicit type checking anyway, they'd
be duck-hunting.  :)


cheers,

-hoss

David Hostetler
neg...@gm...



On Tue, Jan 4, 2011 at 09:18, Stefan Parviainen <pa...@ik...> 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> >  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. Yet integer conversion from a string happens automatically. Why
> does not list conversion happen?
>
> > 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.
>
> 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.
>
> --
> Stefan Parviainen
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

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

Re: [Configobj-develop] List handling in Validator

[Stefan P. <pa...@ik...>]

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.

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

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

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

>  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. Yet integer conversion from a string happens automatically. Why
does not list conversion happen?

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

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.

-- 
Stefan Parviainen