configobj-develop — Support and development of ConfigObj

[Configobj-develop] Re: ConfigObj

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

Tjaart wrote:
>
> Hi Michael.
>
Hello Tjaart,

I've copied this reply to the configobj-develop mailing list as it 
raises an important question about ConfigObj,

Note that you didn't attach the config file, however your email has an 
important clue :

> When I change the line which reads “bind =” to have a value then 
> everything’s fine, is this a bug or am I doing something wrong?.
This is an 'empty value', which as far as I remember is part of the 
'ini' file spec, but not currently legal syntax for ConfigObj.

The correct way of specifying an empty value for ConfigObj is to do :

bind = ''

So it's not your inexperience - that part of the config file simply 
isn't legal syntax for ConfigObj at the moment.

Nicola (ConfigObj co-developer) - the last three support queries I've 
had for ConfigObj have all been to do with empty values. It seems that a 
lot of people are using ConfigObj to parse ini files created elsewhere.

IIRC the empty value *is* part of the normal ini spec. (A later version 
of ConfigObj 3 supported them.) Would you object to me extending 
ConfigObj to read empty values ?

A logical counterpart to this is an additional option (default False) 
allowing you to specify that ConfigObj should write out empty values in 
place of the empty string.

What do you think ?

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> I am working with the following file abc.conf included in my email, 
> when I open it with ConfigObj I get the following error.
>
> >>> config = ConfigObj("C:\Python24\abc.conf", configspec="abc.conf")
>
> Traceback (most recent call last):
>
> File "<stdin>", line 1, in ?
>
> File "C:\Python24\lib\site-packages\pythonutils\configobj.py", line 
> 1069, in _
>
> _init__
>
> self._handle_configspec(defaults['configspec'])
>
> File "C:\Python24\lib\site-packages\pythonutils\configobj.py", line 
> 1731, in _
>
> handle_configspec
>
> raise ConfigspecError('Parsing configspec failed: %s' % e)
>
> configobj.ConfigspecError: Parsing configspec failed: Parse error in 
> value at li
>
> ne 19.
>
> >>>
>
> When I change the line which reads “bind =” to have a value then 
> everything’s fine, is this a bug or am I doing something wrong?.
>
> Sorry but I am very new to python can you maybe give me an example of 
> how to read the value(10) from line 12 which reads “myvalue = 10”
>
> I am really struggling with ConfigObj due to my lack of experience.
>
> Thanks for your help
>
> Regards Tjaart.
>

[Configobj-develop] New Pythonutils Subversion Repository

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

{emo;python} `Pythonutils <http://www.voidspace.org.uk/python/pythonutils.html>`_ also has a new Subversion repository. This now includes `ConfigObj 4.2.0 <http://www.voidspace.org.uk/python/configobj.html>`_ and a slightly updated version of `pathutils <http://www.voidspace.org.uk/python/pathutils.html>`_.

    http://svn.pythonutils.python-hosting.com/

Once again this is thanks to the folks at `Python-hosting.com <http://www.python-hosting.com>`_.

This means that the `rest2web <http://www.voidspace.org.uk/python/rest2web/>`_ now *only* has **rest2web** in it. {sm;:-p}

Re: [Configobj-develop] General Questions.

[Fuzzyman <fuz...@vo...>]

George Flaherty wrote:
>
> -----Original Message-----
> From: con...@li... 
> [mailto:con...@li...] On Behalf Of 
> Michael Foord
> Sent: Monday, February 27, 2006 3:31 PM
> To: con...@li...
> Subject: Re: [Configobj-develop] General Questions.
>
> George Flaherty wrote:
> > I have been evaluating ConfigObj4 and I was wondering if you could 
> answer two questions.....
> >
> > 1. Can I have an ini file with empty values and some other values? 
> Or am I missing some default option?
> > Assume I have the following property file (notice no sections)
> >
> > foobar.mapfile=junk
> > #Path to the .xml mapfile
> >
> > foobar.mapfile.name=morejunk
> > #Path to the mapfile
> >
> > foobar.export.csvpath=
> > #Path to the csv directory
> >
> >  
> Empty values are not currently supported by ConfigObj. Are they 
> standard in most other tools that use an 'ini style' format ?
>
> I've never come across them before, but this is the second question 
> about them in as many weeks.
>
>
> [George]
> Yeah....I really shouldn't call this an ini file, it's really a 
> property file. In my case which might not be standard, I could run 
> into an empty value within a key=value pair.
>
> Yet there is a happy ending to this issue. I wrote a java subclass 
> which writes out "these" property files, and enforced that all values 
> of the key=value pairs will have some type of value. Now I can 
> successfully parse the property file with ConfigObj4...
>
Great.

Note that the following is perfectly valid for ConfigObj :

    key = ''

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Thanks for your help. I will now review the ConfigObj4 code to see if 
> I can modify it for ${value} vs %(value)s
>
> george
>
> [/George]
>
>  
>  
>
>
>

RE: [Configobj-develop] General Questions.

[George F. <Geo...@sa...>]

-----Original Message-----
From: con...@li... =
[mailto:con...@li...] On Behalf Of =
Michael Foord
Sent: Monday, February 27, 2006 3:31 PM
To: con...@li...
Subject: Re: [Configobj-develop] General Questions.

George Flaherty wrote:
> I have been evaluating ConfigObj4 and I was wondering if you could =
answer two questions.....
>
> 1. Can I have an ini file with empty values and some other values? Or =
am I missing some default option?
> Assume I have the following property file (notice no sections)
>
> foobar.mapfile=3Djunk
> #Path to the .xml mapfile
>
> foobar.mapfile.name=3Dmorejunk
> #Path to the mapfile
>
> foobar.export.csvpath=3D
> #Path to the csv directory
>
> =20
Empty values are not currently supported by ConfigObj. Are they standard =
in most other tools that use an 'ini style' format ?

I've never come across them before, but this is the second question =
about them in as many weeks.


[George]
Yeah....I really shouldn't call this an ini file, it's really a property =
file. In my case which might not be standard, I could run into an empty =
value within a key=3Dvalue pair.

Yet there is a happy ending to this issue. I wrote a java subclass which =
writes out "these" property files, and enforced that all values of the =
key=3Dvalue pairs will have some type of value. Now I can successfully =
parse the property file with ConfigObj4...


Thanks for your help. I will now review the ConfigObj4 code to see if I =
can modify it for ${value} vs %(value)s

george

[/George]

=20
=20

Re: [Configobj-develop] General Questions.

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

George Flaherty wrote:
> I have been evaluating ConfigObj4 and I was wondering if you could answer two questions.....
>
> 1. Can I have an ini file with empty values and some other values? Or am I missing some default option?
> Assume I have the following property file (notice no sections)
>
> foobar.mapfile=junk
> #Path to the .xml mapfile
>
> foobar.mapfile.name=morejunk
> #Path to the mapfile
>
> foobar.export.csvpath=
> #Path to the csv directory
>
>   
Empty values are not currently supported by ConfigObj. Are they standard 
in most other tools that use an 'ini style' format ?

I've never come across them before, but this is the second question 
about them in as many weeks.

> My test code is the following:
> --------------------------------------------
> from configobj import ConfigObj
> import os
> import string
>
> def test():
>     configFile = os.path.join('C:/georgef/work/pyWork/classes','test.properties')
>     configHandler = ConfigObj(configFile)
>     return configHandler['marketmax.export.csvpath']
>
> if __name__ == '__main__':
>     print test()
>
> ***But this is raising a Parsing Error?
> Which seems to come from the empty property of "foobar.export.csvpath="
> Am I just missing some option?
>
>
> 2. I am attempting to utilize a single ini file to drive python and ant build scripts. So it would be ideal utilize a "sort-of-ant/java-interpolation" if possible: Again assume I have the following ini file.
>
> Myhome.dir=C:/foo/bar
> Myhome.bin=${Myhome.dir}/bin
>
> Is it possible to do something like ${value} vs. %(value)s?
>
>   
ConfigObj supports ConfigParser style interpolation. Values to be 
interpolated *from* should be in the 'DEFAULT' section.

See the ConfigParser docs for the style of interpolation it uses :

    http://docs.python.org/lib/module-ConfigParser.html

And the ConfigObj docs for ConfigObj specific info :

    http://www.voidspace.org.uk/python/configobj.html#interpolation

Basically is uses '%(name)s', so the short answer would be no.

However, by using the ``walk`` method of ConfigObj and copying the 
interpolation code, it shouldn't be *that* hard to add yourself.

Lack of support for empty values may be a show stopper for you though.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Thank you
> George Flaherty
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>   

[Configobj-develop] General Questions.

[George F. <Geo...@sa...>]

I have been evaluating ConfigObj4 and I was wondering if you could =
answer two questions.....

1. Can I have an ini file with empty values and some other values? Or am =
I missing some default option?
Assume I have the following property file (notice no sections)

foobar.mapfile=3Djunk
#Path to the .xml mapfile

foobar.mapfile.name=3Dmorejunk
#Path to the mapfile

foobar.export.csvpath=3D
#Path to the csv directory

My test code is the following:
--------------------------------------------
from configobj import ConfigObj
import os
import string

def test():
    configFile =3D =
os.path.join('C:/georgef/work/pyWork/classes','test.properties')
    configHandler =3D ConfigObj(configFile)
    return configHandler['marketmax.export.csvpath']

if __name__ =3D=3D '__main__':
    print test()

***But this is raising a Parsing Error?
Which seems to come from the empty property of =
"foobar.export.csvpath=3D"
Am I just missing some option?


2. I am attempting to utilize a single ini file to drive python and ant =
build scripts. So it would be ideal utilize a =
"sort-of-ant/java-interpolation" if possible: Again assume I have the =
following ini file.

Myhome.dir=3DC:/foo/bar
Myhome.bin=3D${Myhome.dir}/bin

Is it possible to do something like ${value} vs. %(value)s?


Thank you
George Flaherty

Re: [Configobj-develop] Default Values

[Fuzzyman <fuz...@vo...>]

Mark Leonard wrote:
> Fuzzyman wrote:
>> Untested, but should work. ;-)
> It does, thanks for the help!
>
Good.

>> I changed a lot in the implementation of unicode from 4.2.0 beta 2 to 
>> the released version, as well as other tinkerings. (See the homepage 
>> http://www.voidspace.org.uk/python/configobj.html for a download 
>> link). I would highly recommend using the latest version.
>
> It seems I am indeed using the latest version, obtained from this link:
> http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj-4.2.0.zip 
>
>
> However, in configobj.py, line 106:
> __version__ = '4.2.0beta2'
>
Ah.... oops. :-)

I'll correct that tonight.

Thanks

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Cheers,
> -Mark
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

Re: [Configobj-develop] Default Values

[Mark L. <mw...@po...>]

Fuzzyman wrote:
> Untested, but should work. ;-)
It does, thanks for the help!

> I changed a lot in the implementation of unicode from 4.2.0 beta 2 to 
> the released version, as well as other tinkerings. (See the homepage 
> http://www.voidspace.org.uk/python/configobj.html for a download link). 
> I would highly recommend using the latest version.

It seems I am indeed using the latest version, obtained from this link:
http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj-4.2.0.zip

However, in configobj.py, line 106:
__version__ = '4.2.0beta2'

Cheers,
-Mark

Re: [Configobj-develop] Default Values

[Fuzzyman <fuz...@vo...>]

Mark Leonard wrote:
> According to the docs:
> http://www.voidspace.org.uk/python/configobj.html#default-values
> "You can set a default value in your check. If the value is missing 
> from the config file then this value will be used instead."
>
> I think I'm making an incorrect assumption about retrieving default 
> values from the dict, as illustrated here:
>
> File test.spec containing only:
> key1 = integer(0, 30, default=15)
> key2 = integer(default=15)
>
> File test.conf containing only:
> key1 = 5
>
> >>> c = ConfigObj( 'test.conf', configspec='test.spec' )
> >>> c
> {'key1': '5'}
> >>> c.configspec
> {'key2': 'integer(default=15)', 'key1': 'integer(0, 30, default=15)'}
> >>> c['key1']
> '5'
> >>> c['key2']
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "C:\Python24\Lib\site-packages\configobj.py", line 337, in 
> __getitem__
>    val = dict.__getitem__(self, key)
> KeyError: 'key2'
>
> Shouldn't this return the default value, in this case 15? Is there a 
> different method I should be using for retrieving values? I can't find 
> anything in the documentation or via introspection. I specifically 
> want the defaults specified in an external file and not in the code 
> using something like c.get('key2',15).
>
Your logic is correct - but missing one step.

The default values are filled in by the validation process (as is the 
type conversion to integers).

 >>> from configobj import ConfigObj
 >>> from validate import Validator
 >>> c = ConfigObj( 'test.conf', configspec='test.spec' )
 >>> c
{'key1': '5'}
 >>> c.configspec
{'key2': 'integer(default=15)', 'key1': 'integer(0, 30, default=15)'}
 >>> v = Validator()
 >>> test = c.validate(v)
 >>> if test != True:
...    print 'Something went wrong ;-)'
 >>> c['key2']
15

Untested, but should work. ;-)

Let me know if it doesn't.

> I'm using configobj version 4.2.0beta2
>
I changed a lot in the implementation of unicode from 4.2.0 beta 2 to 
the released version, as well as other tinkerings. (See the homepage 
http://www.voidspace.org.uk/python/configobj.html for a download link). 
I would highly recommend using the latest version.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Cheers,
> -Mark
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

[Configobj-develop] Default Values

[Mark L. <mw...@po...>]

According to the docs:
http://www.voidspace.org.uk/python/configobj.html#default-values
"You can set a default value in your check. If the value is missing from 
the config file then this value will be used instead."

I think I'm making an incorrect assumption about retrieving default 
values from the dict, as illustrated here:

File test.spec containing only:
key1 = integer(0, 30, default=15)
key2 = integer(default=15)

File test.conf containing only:
key1 = 5

 >>> c = ConfigObj( 'test.conf', configspec='test.spec' )
 >>> c
{'key1': '5'}
 >>> c.configspec
{'key2': 'integer(default=15)', 'key1': 'integer(0, 30, default=15)'}
 >>> c['key1']
'5'
 >>> c['key2']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\Lib\site-packages\configobj.py", line 337, in 
__getitem__
    val = dict.__getitem__(self, key)
KeyError: 'key2'

Shouldn't this return the default value, in this case 15? Is there a 
different method I should be using for retrieving values? I can't find 
anything in the documentation or via introspection. I specifically want 
the defaults specified in an external file and not in the code using 
something like c.get('key2',15).

I'm using configobj version 4.2.0beta2

Cheers,
-Mark

Re: [Configobj-develop] Re: ConfigObj 4.2.0

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

>>> It's main feature

>> Should be "Its"

>>> It's features include :

>> Should be "Its"

> Not you as *well*. I get enough of that from Nicola. :-)
> 
> Not that you're not correct of course...

Aaron, while we're at it, I could really use your help in convincing
Michael that question and exclamation marks really need no space before
them. Thanks in advance.

B-P (to Mike)

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

Yeah! Another web framework for Python! Now we can proudly say:
Python: the only language with more web frameworks than keywords.
 -- Harald A. Massa, December 2005

[Configobj-develop] Re: ConfigObj 4.2.0

[Fuzzyman <fuz...@vo...>]

Aaron Bentley wrote:

> Thanks.  I've merged ConfigObj 4.2.0 into the bzr mainline.  It will
> appear in the bzr 0.8 release.
>
Great.

> fuz...@vo... wrote:
>
> | It's main feature
>
> Should be "Its"
>
> | It's features include :
>
> Should be "Its"
>
Not you as *well*. I get enough of that from Nicola. :-)

Not that you're not correct of course...

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Aaron

[Configobj-develop] Re: ConfigObj 4.2.0

[Aaron B. <aar...@ut...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks.  I've merged ConfigObj 4.2.0 into the bzr mainline.  It will
appear in the bzr 0.8 release.

fuz...@vo... wrote:

| It's main feature

Should be "Its"

| It's features include :

Should be "Its"

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD+oyh0F+nu1YWqI0RAiD8AJ4oSo+d7yL8xgHjXssXKaME7znLdgCeKZu1
oGMg56bW+Y9fFmIfSaHFQ4c=
=d1G7
-----END PGP SIGNATURE-----

Re: [Configobj-develop] Finally getting to use ConfigObj :-)

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

Nicola Larosa wrote:
>> I'd like to minimise any future API growth as much as possible.
>>
>> I'd like to *consider* removing the following methods :
>>
>>   encode
>>   decode
>>   rename
>>     
>
>
> Negative API growth is good. :-)
> [snip..]

encode, decode and rename will be deprecated in the next release.

>
>   
>> After Guido's comments I'd even consider *not* subclassing dict, and
>> only implementing those mapping protocol methods that are actually
>> appropriate. Ripping stuff out isn't my *immediate* priority though.
>>     
>
> We have yet to check whether being a dict subclass helps, or not, with
> Twisted's Perspective Broker serialization. I'll let you know.
>
>
>   
I thought you already knew that it didn't ?

>> I've also wondered if there might be any use for a 'ConfigObj-lite' ?
>> ConfigObj now weighs in at around 115k, which is quite hefty if all you
>> want to do is *read* config files.
>>     
>
> More than half of it are doctests, and even more than that for validate.py.
> I'd rather *increase* the size of the archive by including the 2.4 version
> of doctest.py from the stdlib. That way we could separate the doctests in
> their own files, and still have them work on Python 2.2 and 2.3.
>
> That would bring down the file sizes even for the full-feature version.
>
>
>   
+1 if you backport doctest for 2.2 compatibility. :-)

There's a lot of CHANGELOG accumulating *in* the source as well. We 
don't want such a detailed changelog in the docs, so we could either 
move it to a separate file or not worry about it.

If the doctest backport is a possibility, I won't worry about 
configobj-lite until some actually requests it (with a convincing 
use-case). Subclassing is more complicated than you suggest, because 
some of the 'removable' features are in ``Section``. Not a priority in 
any case.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Configobj-develop] Finally getting to use ConfigObj :-)

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

> I'd like to minimise any future API growth as much as possible.
> 
> I'd like to *consider* removing the following methods :
> 
>   encode
>   decode
>   rename

Negative API growth is good. :-)


> I do know of at least two users who use the ``walk`` method, so we
> probably need to keep it.

I'd keep that one, yes.


> One possibly uses the rename method. Hmmm...

Is it just a shortcut for one reassignment plus one deletion? It doesn't
seem worth much.


> After Guido's comments I'd even consider *not* subclassing dict, and
> only implementing those mapping protocol methods that are actually
> appropriate. Ripping stuff out isn't my *immediate* priority though.

We have yet to check whether being a dict subclass helps, or not, with
Twisted's Perspective Broker serialization. I'll let you know.


> I've also wondered if there might be any use for a 'ConfigObj-lite' ?
> ConfigObj now weighs in at around 115k, which is quite hefty if all you
> want to do is *read* config files.

More than half of it are doctests, and even more than that for validate.py.
I'd rather *increase* the size of the archive by including the 2.4 version
of doctest.py from the stdlib. That way we could separate the doctests in
their own files, and still have them work on Python 2.2 and 2.3.

That would bring down the file sizes even for the full-feature version.


> It occurs to me that it would be possible to create a much smaller
> 'reader only' which doesn't support validation or writing. That would be
> especially true if some of the dictionary methods were also removed. It
> wouldn't be very much work as it would be almost straight 'ripping-out'
> of code.

Having done the above, maybe a read-only version wouldn't be that much
appealing anymore. Even if it would still be so, I would not manage and
distribute it separately, but maybe have the read-write one subclass, and
add one file to, the read-only one.

But I wonder whether it would be worthy the added complication.

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

...I do no real world applications like triple mersenne first person
shooters, only business software like the one which in earlier time
was written in COBOL or carved into cave walls. Less challenge,
higher reward. -- Harald Armin Massa, November 2005

Re: [Configobj-develop] Finally getting to use ConfigObj :-)

[Fuzzyman <fuz...@vo...>]

Nicola Larosa wrote:
> After many months, we are actually starting to use ConfigObj on the job.
> Expect many comments and fixes soon. :-)
>
> Let me also introduce my esteemed colleague, Francesco Del Degan.
> Francesco, please subscribe to this mailing list, and start firing away. :-)
Fixes :-o
 
Are you maligning our code ;-)
 
Anyway, that's good news.
 
I'd like to minimise any future API growth as much as possible.
 
I'd like to *consider* removing the following methods :
 
   encode
   decode
   rename
 
I do know of at least two users who use the ``walk`` method, so we 
probably need to keep it. One possibly uses the rename method. Hmmm...

After Guido's comments I'd even consider *not* subclassing dict, and 
only implementing those mapping protocol methods that are actually 
appropriate. Ripping stuff out isn't my *immediate* priority though.

I've also wondered if there might be any use for a 'ConfigObj-lite' ? 
ConfigObj now weighs in at around 115k, which is quite hefty if all you 
want to do is *read* config files.

It occurs to me that it would be possible to create a much smaller 
'reader only' which doesn't support validation or writing. That would be 
especially true if some of the dictionary methods were also removed. It 
wouldn't be very much work as it would be almost straight 'ripping-out' 
of code.

Anyway, this all me just 'thinking-aloud'. Feel free to comment or not. :-)

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

[Configobj-develop] Finally getting to use ConfigObj :-)

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

After many months, we are actually starting to use ConfigObj on the job.
Expect many comments and fixes soon. :-)

Let me also introduce my esteemed colleague, Francesco Del Degan.
Francesco, please subscribe to this mailing list, and start firing away. :-)

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

...I do no real world applications like triple mersenne first person
shooters, only business software like the one which in earlier time
was written in COBOL or carved into cave walls. Less challenge,
higher reward. -- Harald Armin Massa, November 2005

[Configobj-develop] ConfigObj 4.2.0

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

{emo;home} `ConfigObj 4.2.0 <http://www.voidspace.org.uk/python/configobj.html>`_ is now available.

The main improvements are *full* Unicode support,a s well as the addition of the 'convenience' `Section Methods <http://www.voidspace.org.uk/python/configobj.html#section-methods>`_

* *as_bool*
* *as_int*
* *as_float*

More compelling reasons to choose **ConfigObj** for reading and writing config files in Python. {sm;:-)}

{title;What's New ?}

The full changelog is :

Removed ``BOM_UTF8`` from ``__all__``.

The ``BOM`` attribute has become a boolean. (Defaults to ``False``.) It is *only* ``True`` for the ``UTF16`` encoding.

File like objects no longer need a ``seek`` attribute.

Full unicode support added. New options/attributes ``encoding``, ``default_encoding``.

ConfigObj no longer keeps a reference to file like objects. Instead the ``write`` method takes a file like object as an optional argument. (Which will be used in preference of the ``filename`` attribute if that exists as well.)

utf16 files decoded to unicode.

If ``BOM`` is ``True``, but no encoding specified, then the utf8 BOM is written out at the start of the file. (It will normally only be ``True`` if the utf8 BOM was found when the file was read.)

File paths are *not* converted to absolute paths, relative paths will remain relative as the ``filename`` attribute.

Fixed bug where ``final_comment`` wasn't returned if ``write`` is returning a list of lines.

Deprecated ``istrue``, replaced it with ``as_bool``.

Added ``as_int`` and ``as_float``.

{title;What is ConfigObj ?}

**ConfigObj** is a simple but powerful config file reader and writer: an *ini file round tripper*.

It's main feature is that it is very easy to use, with a straightforward programmer's interface and a simple syntax for config files. It has lots of other features though. It is intended as a more powerful (but simpler to use) replacement for `ConfigParser <http://docs.python.org/lib/module-ConfigParser.html>`_.

It's features include :

* Nested sections (subsections), to any level
* List Values
* Multiple Line Values
* Full Unicode support
* String interpolation (substitution)
* Integrated with a powerful validation system

    - including automatic type checking/conversion
    - repeated sections
    - and allowing default values

* All comments in the file are preserved
* The order of keys/sections is preserved
* No external dependencies

[Configobj-develop] Re: ConfigObj 4.2.0 Beta 2

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

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> fuz...@vo... wrote:
>   
>> This now has a set of tests and I'm happy with the changes. If no bugs
>> are found, then this will become *ConfigObj 4.2.0*. I'm happy with the
>> changes.
>>     
>
> You seem to be very happy with the changes!  So am I.  When it's
> released, I'll push my changes into mainline bzr.
>   
Ha, I am pleased. I spotted the typo before uploading, but not before 
mailing. *oops*

Thanks. I'll wait a few days to see if any bug reports come. I've still 
got to modify the docs anyway.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
> Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFD7Nrc0F+nu1YWqI0RAgmHAKCJuuaxZU3v1HtzTsbUzhj/ApQqoQCdFbyC
> BQCVi8CJSD8gkl8f1XAjVXE=
> =LLbX
> -----END PGP SIGNATURE-----
>
>   

[Configobj-develop] Re: ConfigObj 4.2.0 Beta 2

[Aaron B. <aar...@ut...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fuz...@vo... wrote:
> This now has a set of tests and I'm happy with the changes. If no bugs
> are found, then this will become *ConfigObj 4.2.0*. I'm happy with the
> changes.

You seem to be very happy with the changes!  So am I.  When it's
released, I'll push my changes into mainline bzr.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD7Nrc0F+nu1YWqI0RAgmHAKCJuuaxZU3v1HtzTsbUzhj/ApQqoQCdFbyC
BQCVi8CJSD8gkl8f1XAjVXE=
=LLbX
-----END PGP SIGNATURE-----

[Configobj-develop] ConfigObj 4.2.0 Beta 2

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

{emo;development} I've just checked an updated version of `ConfigObj <http://www.voidspace.org.uk/python/configobj.html>`_ into the subversion repository. This is **ConfigObj 4.2.0 Beta 2**, and it's in the usual place :

    https://svn.rest2web.python-hosting.com/branches/configobj4/pythonutils/

This now has a set of tests and I'm happy with the changes. If no bugs are found, then this will become **ConfigObj 4.2.0**. I'm happy with the changes.

.. warning::

   The way that ConfigObj handles file like objects has changed. It no longer keeps a reference to them. This is *better*, but could break existing code.

    Additionally, the {acro;BOM;Byte Order Mark} attribute is now a boolean.

I haven't yet done the documentation, but these are the changes :

* Full unicode support.

    You can specify an ``encoding`` and a ``default_encoding`` when you create your instance.

    The ``encoding`` keyword maps to the ``encoding`` attribute. It is used to decode your config file into unicode, and also to re-encode when writing.

    The ``default_encoding`` (if supplied) is used to decode any byte-strings that have got into your ConfigObj instance, before writing in the specified encoding. This overrides the system default encoding that is otherwise used.

* UTF16 Handling

    ``UTF16`` encoded files are automatically detected and decoded to unicode. This is because ConfigObj *can't* handle them as byte strings.

* BOM Attribute

    The BOM attribute is now a boolean. If a UTF8 or UTF16 BOM was detected then it is ``True``. The default is ``False``.

    If BOM is ``True``, then a UTF8 BOM will be written out with files that have no encoding specified, or have a ``utf_8`` encoding.

* File like Objects.

    ConfigObj no longer keeps a reference to file like objects you pass it. If you create a ConfigObj instance from a file like object, the ``filename`` attribute will be ``None``.

    In addition to this, the ``seek`` method of file like objects is never called by ConfigObj. (It tests for the ``read`` method when you instantiate. You must call ``seek(0)`` yourself first, if necessary. This means you can use file like objects which don't implement seek.

* Writing to a file like object.

    The ``write`` method can now receive an optional file like object as an argument. This will be written to in preference to a file specified by the ``filename`` attribute.

* Line Endings.

    When passed a config file (by whatever method), ConfigObj will attempt to determine the line endings in use. (It chooses the first line ending character it finds, whether this be ``\r\n``, ``\n``, or ``\r``.)

    This is preserved as the ``newlines`` attribute.

    When writing (except when outputting a list of lines), this will be used as the line endings for the file.

    For new ConfigObj instances (or where no line endings are found), it defaults to ``None``. In this case the platform native line ending (``os.linesep``) is used.

There are also the new `Section Methods <http://www.voidspace.org.uk/python/configobj.html#section-methods>`_ added in Beta 1 :

* ``as_bool``
* ``as_int``
* ``as_float``

They all take a single key as an argument, and return the value in the specified type. They can all raise ``KeyError`` or ``ValueError`` should the situation demand it.

Re: [Configobj-develop] Re: ConfigObj unicode Support in SVN

[Fuzzyman <fuz...@vo...>]

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Foord wrote:
> | I realise that in Python it is more common to pass around file like
> | objects than filenames. I guess this is more object oriented because of
> | the "like" bit. However it has always felt more awkward to me, because
> |  >90% of the time I use "file-like" objects, they are file objects.
>
> For Bazaar-NG, the file-like objects currently represent http, sftp and
> ftp downloads and uploads.  Not saying either way is best, or even that
> you have to change things.  What we have now does work, after all, and I
> appreciate the changes you've made so far.
>
Thanks for your comments. Fixes discussed so far will be ready over the 
weekend.

I *do* think it's weird that ConfigObj uses the filename attribute to 
store a reference to the file object/StringIO instance you pass in.

This is illogical at best, and can lead to errors if you would normally 
expect a file object to be garbage collected. (It's better practise to 
close explicitly, but hey.)

I think the best change is to *not* store a reference to 
"file-like-objects" passed in to ConfigObj, but change the ``write`` 
method to receive an optional file object as an argument.

This is backwards incompatible - but because of all the changes I'm 
bumping the version number to 4.2.0.

I'm open to protests from anyone else before I make this change...

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
> Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFD4rOU0F+nu1YWqI0RAudeAJ0fnGEecu5wVMNyLa4UiWyJ1ft5gQCfbEq+
> 49JZmbgE0HaX8AtpzA6Jn9Q=
> =RNuq
> -----END PGP SIGNATURE-----
>

Re: [Configobj-develop] Re: ConfigObj unicode Support in SVN

[Aaron B. <aar...@ut...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Foord wrote:
| I realise that in Python it is more common to pass around file like
| objects than filenames. I guess this is more object oriented because of
| the "like" bit. However it has always felt more awkward to me, because
|  >90% of the time I use "file-like" objects, they are file objects.

For Bazaar-NG, the file-like objects currently represent http, sftp and
ftp downloads and uploads.  Not saying either way is best, or even that
you have to change things.  What we have now does work, after all, and I
appreciate the changes you've made so far.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD4rOU0F+nu1YWqI0RAudeAJ0fnGEecu5wVMNyLa4UiWyJ1ft5gQCfbEq+
49JZmbgE0HaX8AtpzA6Jn9Q=
=RNuq
-----END PGP SIGNATURE-----

Re: [Configobj-develop] Re: ConfigObj unicode Support in SVN

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

Nicola Larosa wrote:
>>> My preference would be the ability to specify a file object to
>>> cfg_obj.write().
>>>       
>
>   
>> So you'd like to be able to pass a file like object to ``write()``...
>> hmmm...
>>
>> Again, this is something that you used to be able to do with ConfigObj
>> 3, but I removed to reduce the level of complexity.
>>
>> To be symmetric with initialisation, you ought then be able to pass in a
>> filename as well. Seeing as you can already achieve this just be setting
>> the ``filename`` attribute (which ok sounds a little weird for this
>> purpose), I decided not to do it.
>>
>> Hmmm... I guess it wouldn't hurt being able to pass an optional file
>> object to write, it's just that the API keeps growing...
>>
>> Nicola, do you have any take on this ?
>>     
>
> Well, it actually feels a little awkward that ConfigObj is in the business
> of opening files, and having to store the filename in an attribute. It
> seems best that ``write`` just receives a file-like object, and be done
> with it.
>
> This seems a worthy addition to me. At this point you probably have to keep
> the filename attribute for compatibility anyway, but maybe you could even
> find a way to deprecate it? :-)
>   

I realise that in Python it is more common to pass around file like 
objects than filenames. I guess this is more object oriented because of 
the "like" bit. However it has always felt more awkward to me, because 
 >90% of the time I use "file-like" objects, they are file objects.

Invariably when I write a config file, it is to the same one that was 
opened. My current idiom (based on having a hardwired config filename, 
or retrieving from the user) is :

    retrieve filename
    instantiate ConfigObj
    ..
    do stuff
    ..
    write

The alternative becomes :

    get filename
    open file
    instantiate ConfigObj (whilst keeping a separate reference to the 
filename)
    close file
    ..
    do stuff
    ..
    get filename again
    open file
    write
    close file

It just seems a lot more awkward. ConfigObj *already* supports passing 
it an open file on instantiation. I guess passing an open file to 
``write`` is a logical extension of this, but I won't deprecate 
``filename``.

All the best,


Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Configobj-develop] Re: ConfigObj unicode Support in SVN

[Aaron B. <aar...@ut...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Foord wrote:
>> Ok - so if an encoding is specified, then ``write()`` should always
>> return byte strings. That is what is called an 'over-sight'. :-)
> 
>> Will be fixed.

Cool.

> My preference would be the ability to specify a file object to
> cfg_obj.write().
>   
> 
>> So you'd like to be able to pass a file like object to ``write()``...
>> hmmm...
> 
>> Again, this is something that you used to be able to do with ConfigObj
>> 3, but I removed to reduce the level of complexity.

By way of explanation, the file-like objects we read from are not the
same objects as the ones we write to.  We have a get method that
produces a read-only file-like, and a put method that accepts a file-like.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD4lyF0F+nu1YWqI0RAiXmAJ0TuLzcDOjtLBi4LghjjMSc/mQm6QCcDi31
dkl8c/9AJMfneuT5S88hPYU=
=qHDM
-----END PGP SIGNATURE-----