configobj-develop — Support and development of ConfigObj

[Configobj-develop] Validate and default=""

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

Hello all,

There was a reported bug that using default="" with validate was broken, 
so I will be looking at that.

There are a lot of fairly chunky regular expressions in validate...


Michael

[Configobj-develop] Validate Strings as list type

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

Hello guys,

I'm looking at the problem that specifying a list type with validate can 
let strings through unchanged.

The problem is simple enough - validate calls len on arguments and 
assumes that anything with a length is a list!


    try:
        length = len(value)
    except TypeError:
        raise VdtTypeError(value)

The question is how to fix it. As strings are an odd sequence type, I 
propose to add a specific 'isinstance(value, basestring)' check to catch 
strings. I also propose to return list(value) as validate is supposed to 
guarantee the return type of validated values.

A side effect of this is that tuples validated as lists will become 
lists. If this is a problem I could add 'is_tuple' equivalents to the 
'is_list' validate functions... (Differing not on what input they 
accept, but only on the type of the returned value...)

Michael Foord
http://www.manning.com/foord

Re: [Configobj-develop] Strings with "#" should be quoted before writing

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

Hello Osmo,

This problem with ConfigObj is now fixed in SVN. Sorry it took so long. 
A new release will follow shortly.

Michael

Osmo Salomaa wrote:
> Hello,
>
> I use configobj and validate to store configurations in Gaupol [1].  One
> of the things saved  in the configuration file is a list of patterns the
> user has searched for.  I just noticed that if the user searches for
> "#", the string gets saved in the configuration file with no escaping or
> quoting and upon reading seems to be interpreted as an in-line comment.
> This is especially problematic if "#" is the first item in the list, in
> which case the value is interpreted as an empty string instead of an
> empty list!
>
> I think the following patch to the "_quote" method should fix that.
>
> --- configobj.orig.py   2007-07-16 02:18:27.000000000 +0300
> +++ configobj.py        2007-07-16 02:20:46.000000000 +0300
> @@ -1674,7 +1674,7 @@
>                      value)
>              elif ((value[0] not in wspace_plus) and
>                      (value[-1] not in wspace_plus) and
> -                    (',' not in value)):
> +                    (',' not in value) and ('#' not in value)):
>                  quot = noquot
>              else:
>                  if ("'" in value) and ('"' in value):
>
> [1] http://home.gna.org/gaupol/
>
> Thanks,
> Osmo Salomaa
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>   

[Configobj-develop] ConfigObj and IPython

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

Hello,

I've just discovered that IPython is using ConfigObj. Fernando Perez has 
developed a module called 'TConfig' that combines ConfigObj with 
enthought Traits !

http://ipython.scipy.org/ipython/ipython/browser/ipython/branches/saw/sandbox/tconfig.py?rev=2526

They use unrepr mode, and the parameters they use to create a ConfigObj are:

configobj.ConfigObj(filename,
                                   create_empty=True,
                                   indent_type='    ',
                                   interpolation='Template',
                                   unrepr=True)

It interests me what configuration people use as there as so many with 
ConfigObj now...

Michael

[Configobj-develop] Newlines and hashes in keys/values

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

Hello all,

Just let you know that fixes for the following issues are in SVN:

* Guaranteeing config files are newline terminated
* Properly quoting hashes in keys/values/list values

It turns out that you can use triple quotes, even when list values are 
switched off. When a value contains a hash and list values are False, 
they are written with triple quotes. The code that does all this is 
*still* too hard to read and probably needs breaking into several methods.

Michael
http://www.manning.com/foord

Re: [Configobj-develop] ConfigObj Changes

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

Nicola Larosa wrote:
> Michael Foord wrote:
>   
>> If there are any other (small!) things to look at then speak up now. For 
>> larger changes the 'patches welcome' rule applies I'm afraid.
>>     
>
> I've been sitting on a bug report about newlines on Windows for some time
>  (sorry). It's in Italian, I'll translate it and send it here soon.
>
>   
Ok - cool. But how many problems with newlines can there *be*? :-)

Michael

Re: [Configobj-develop] ConfigObj Changes

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

Michael Foord wrote:
> If there are any other (small!) things to look at then speak up now. For 
> larger changes the 'patches welcome' rule applies I'm afraid.

I've been sitting on a bug report about newlines on Windows for some time
 (sorry). It's in Italian, I'll translate it and send it here soon.

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

Just as a painter starts from a black canvas, a musician should start
from silence; and one of our most essential skills is the ability to
simply shut up and listen. -- Joe Jackson, A Cure for Gravity, 1999

Re: [Configobj-develop] ConfigObj Changes

[Arve K. <arv...@gm...>]

I have another patch for you, apply this on top of my previous patch. This
updates documentation, and renames the method I added to Validator to
check_default, since I found this better reflects its relation to the check
method.

Arve

On Jan 13, 2008 2:08 PM, Arve Knudsen <arv...@gm...> wrote:

> On 1/13/08, Michael Foord <fuz...@vo...> wrote:
>
> > Arve Knudsen wrote:
> > > Hiya Michael
> > >
> > > Will you be fixing the problem I reported a while back, where
> > > configuration fields declared to be lists, in the specification, can
> > > be interpreted as strings (if you forget to end with a ',')?
> > That's one of the validate issues that I will be looking at.
>
>
> Great.
>
> Arve
>
>
> Michael
> >
> >
> > >
> > > Arve
> > >
> > > On 1/13/08, *Michael Foord* <fuz...@vo...
> > > <mailto: fuz...@vo... >> wrote:
> > >
> > >     Hello guys,
> > >
> > >     I have finally got around to giving ConfigObj some love.
> > >
> > >
> > http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920
> > >     <http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920
> > >
> > >
> > >     Things I will be looking at include:
> > >
> > >         * Guaranteeing that written config files are newline
> > terminated
> > >         * Quoting keys, values and list members that contain hashes
> > >         * Review a patch that adds a restore_defaults method
> > >         * Evaluating how difficult adding a reload method would be
> > >         * A couple of bugfixes to the validate module
> > >
> > >     If there are any other (small!) things to look at then speak up
> > >     now. For
> > >     larger changes the 'patches welcome' rule applies I'm afraid.
> > >
> > >     Michael
> > >     http://www.manning.com/foord
> > >
> > >
> > >
> > -------------------------------------------------------------------------
> > >     Check out the new SourceForge.net Marketplace.
> > >     It's the best place to buy or sell services for
> > >     just about anything Open Source.
> > >     http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> >
> > >     <
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > >
> > >     _______________________________________________
> > >     Configobj-develop mailing list
> > >     Con...@li...
> > >     <mailto: Con...@li...>
> > >     https://lists.sourceforge.net/lists/listinfo/configobj-develop
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > >
> > >
> > -------------------------------------------------------------------------
> > > Check out the new SourceForge.net Marketplace.
> > > It's the best place to buy or sell services for
> > > just about anything Open Source.
> > >
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > >
> > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Configobj-develop mailing list
> > > Con...@li...
> > > https://lists.sourceforge.net/lists/listinfo/configobj-develop
> > >
> >
> >
> > -------------------------------------------------------------------------
> >
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> >
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > Configobj-develop mailing list
> > Con...@li...
> > https://lists.sourceforge.net/lists/listinfo/configobj-develop
> >
>
>

Re: [Configobj-develop] ConfigObj Changes

[Arve K. <arv...@gm...>]

On 1/13/08, Michael Foord <fuz...@vo...> wrote:
>
> Arve Knudsen wrote:
> > Hiya Michael
> >
> > Will you be fixing the problem I reported a while back, where
> > configuration fields declared to be lists, in the specification, can
> > be interpreted as strings (if you forget to end with a ',')?
> That's one of the validate issues that I will be looking at.


Great.

Arve


Michael
>
>
> >
> > Arve
> >
> > On 1/13/08, *Michael Foord* <fuz...@vo...
> > <mailto:fuz...@vo...>> wrote:
> >
> >     Hello guys,
> >
> >     I have finally got around to giving ConfigObj some love.
> >
> >
> http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920
> >     <
> http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920>
> >
> >     Things I will be looking at include:
> >
> >         * Guaranteeing that written config files are newline terminated
> >         * Quoting keys, values and list members that contain hashes
> >         * Review a patch that adds a restore_defaults method
> >         * Evaluating how difficult adding a reload method would be
> >         * A couple of bugfixes to the validate module
> >
> >     If there are any other (small!) things to look at then speak up
> >     now. For
> >     larger changes the 'patches welcome' rule applies I'm afraid.
> >
> >     Michael
> >     http://www.manning.com/foord
> >
> >
> >
> -------------------------------------------------------------------------
> >     Check out the new SourceForge.net Marketplace.
> >     It's the best place to buy or sell services for
> >     just about anything Open Source.
> >
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> >     <
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> >
> >     _______________________________________________
> >     Configobj-develop mailing list
> >     Con...@li...
> >     <mailto:Con...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/configobj-develop
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> >
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Configobj-develop mailing list
> > Con...@li...
> > https://lists.sourceforge.net/lists/listinfo/configobj-develop
> >
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

Re: [Configobj-develop] ConfigObj Changes

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

Arve Knudsen wrote:
> Hiya Michael
>
> Will you be fixing the problem I reported a while back, where 
> configuration fields declared to be lists, in the specification, can 
> be interpreted as strings (if you forget to end with a ',')?
That's one of the validate issues that I will be looking at.

Michael


>
> Arve
>
> On 1/13/08, *Michael Foord* <fuz...@vo... 
> <mailto:fuz...@vo...>> wrote:
>
>     Hello guys,
>
>     I have finally got around to giving ConfigObj some love.
>
>     http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920
>     <http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920>
>
>     Things I will be looking at include:
>
>         * Guaranteeing that written config files are newline terminated
>         * Quoting keys, values and list members that contain hashes
>         * Review a patch that adds a restore_defaults method
>         * Evaluating how difficult adding a reload method would be
>         * A couple of bugfixes to the validate module
>
>     If there are any other (small!) things to look at then speak up
>     now. For
>     larger changes the 'patches welcome' rule applies I'm afraid.
>
>     Michael
>     http://www.manning.com/foord
>
>
>     -------------------------------------------------------------------------
>     Check out the new SourceForge.net Marketplace.
>     It's the best place to buy or sell services for
>     just about anything Open Source.
>     http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>     <http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace>
>     _______________________________________________
>     Configobj-develop mailing list
>     Con...@li...
>     <mailto:Con...@li...>
>     https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ------------------------------------------------------------------------
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>   

Re: [Configobj-develop] ConfigObj Changes

[Arve K. <arv...@gm...>]

Hiya Michael

Will you be fixing the problem I reported a while back, where configuration
fields declared to be lists, in the specification, can be interpreted as
strings (if you forget to end with a ',')?

Arve

On 1/13/08, Michael Foord <fuz...@vo...> wrote:
>
> Hello guys,
>
> I have finally got around to giving ConfigObj some love.
>
> http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920
>
> Things I will be looking at include:
>
>     * Guaranteeing that written config files are newline terminated
>     * Quoting keys, values and list members that contain hashes
>     * Review a patch that adds a restore_defaults method
>     * Evaluating how difficult adding a reload method would be
>     * A couple of bugfixes to the validate module
>
> If there are any other (small!) things to look at then speak up now. For
> larger changes the 'patches welcome' rule applies I'm afraid.
>
> Michael
> http://www.manning.com/foord
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

[Configobj-develop] Hashes in keys and values

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

Hello guys,

ConfigObj has what I consider to be a serious bug. To be honest I'm 
*really* surprised it hasn't been reported before (and that I didn't 
think of it when writing ConfigObj).

Hashes is keys in values aren't quoted.  This means they are read back 
in as comments, breaking the config file.

This is relatively easy to fix (inside the '_quote' method). However, we 
don't quote (or unquote) values when 'list_values' is set to False. This 
means that I don't know what to do.

The first thing to do is to fix the bug for normal operation - even if 
it leaves the bug in place when we're not handling list values.

In the long run it would be better to do the quoting and unquoting when 
list values is off - except I can't remember why it was implemented like 
that in the first place! To change it will also break backwards 
compatibility with existing config files.

I can try and hunt down the reason for the current implementation (I 
think it was convenience but that may not be the case). I don't know 
what to do about the backwards compatibility issue though.

Michael
http://www.manning.com/foord

[Configobj-develop] ConfigObj Changes

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

Hello guys,

I have finally got around to giving ConfigObj some love.

http://www.voidspace.org.uk/python/weblog/arch_d7_2008_01_12.shtml#e920

Things I will be looking at include:

    * Guaranteeing that written config files are newline terminated
    * Quoting keys, values and list members that contain hashes
    * Review a patch that adds a restore_defaults method
    * Evaluating how difficult adding a reload method would be
    * A couple of bugfixes to the validate module

If there are any other (small!) things to look at then speak up now. For 
larger changes the 'patches welcome' rule applies I'm afraid.

Michael
http://www.manning.com/foord

Re: [Configobj-develop] [python] Suggestion for improved defaults handling

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

Arve Knudsen wrote:
> Hi again, Michael
>
> I have now written doctests for the new functionality. In doing so, I 
> discovered there was a problem with my initial implementation: only 
> fields for which there weren't specified any value were registered 
> in the default_values attribute. In order to get at the default values 
> for all fields, I had to make some changes to validate.py as well. The 
> changes should be backwards-compatible from my testing (no doctests 
> break). I've attached the difference against pythonutils trunk.
>

Ah - the value of tests. :-)

Cool. I have a couple more changes to make, so hopefully I can review 
this weekend. I only have a fairly minor writing task first.

Michael

> Arve
>
> On 1/7/08, *Michael Foord* <fuz...@vo... 
> <mailto:fuz...@vo...>> wrote:
>
>     Arve Knudsen wrote:
>     >
>     >
>     > On 1/6/08, *Michael Foord* <fuz...@vo...
>     <mailto:fuz...@vo...>
>     > <mailto:fuz...@vo...
>     <mailto:fuz...@vo...>>> wrote:
>     >
>     >     Hello Arve,
>     >
>     >     Thanks for the patch. I have some work to do on ConfigObj so
>     I will
>     >     include it in that. Any chance you could provide tests and
>     >     documentation?
>     >
>     >
>     > I will have to look at how ConfigObj does docs/tests, hopefully
>     > sometime this week. Do you agree with that there should be a
>     separate
>     > method restore_default, instead of restoring the default as part of
>     > __delitem__?
>
>     Agreed - that sounds better to me. I prefer not to 'proliferate
>     methods', but this change in behaviour would be a bit 'too magical'.
>
>     Michael
>     >
>     > Arve
>     >
>     >     Thanks
>     >
>     >     Michael
>     >
>     >     Arve Knudsen wrote:
>     >     > Hello
>     >     >
>     >     > I found I missed the ability to restore entries to their
>     default
>     >     value
>     >     > in ConfigObj, so that you can differentiate between actualy
>     >     deleting
>     >     > an entry and just restoring it to the default state. My
>     >     suggestion is
>     >     > to track sections' default values with an additional
>     attribute
>     >     > "default_values", and to add a method "restore_default" for
>     >     restoring
>     >     > a particular entry. I also considered restoring default values
>     >     as part
>     >     > of __delitem__, but figured this might be too implicit and
>     breaking
>     >     > backwards compatibility.
>     >     >
>     >     > I hope to see this integrated with ConfigObj upstream as I
>     need
>     >     it in
>     >     > my own project :_)
>     >     >
>     >     > --- configobj.py_orig 2008-01-06 22:33:58.000000000 +0100
>     >     > +++ configobj.py 2008-01-06 22:34:29.000000000 +0100
>     >     > @@ -498,7 +498,8 @@
>     >     > self._cs_section_comments = {}
>     >     > self._cs_section_inline_comments = {}
>     >     > # for defaults
>     >     > - self.defaults = []
>     >     > + self.defaults = [] # Entries that have their default value
>     >     > + self.default_values = {} # The original default values
>     >     > #
>     >     > # we do this explicitly so that __setitem__ is used properly
>     >     > # (rather than just passing to ``dict.__init__``)
>     >     > @@ -751,6 +752,18 @@
>     >     > else:
>     >     > self[key] = val
>     >     > + def restore_default(self, key):
>     >     > + """
>     >     > + Restore default value.
>     >     > +
>     >     > + If there is no default value for this key, ValueError is
>     raised.
>     >     > + """
>     >     > + if key not in self.default_values:
>     >     > + raise ValueError(key)
>     >     > + if key not in self.defaults:
>     >     > + self.defaults.append(key)
>     >     > + dict.__setitem__(self, key, self.default_values[key])
>     >     > +
>     >     > def rename(self, oldkey, newkey):
>     >     > """
>     >     > Change a keyname to another, without changing position in
>     sequence.
>     >     > @@ -2103,6 +2116,7 @@
>     >     > section[entry] = check
>     >     > if not copy and missing and entry not in section.defaults :
>     >     > section.defaults.append(entry)
>     >     > + section.default_values[entry] = check
>     >     > #
>     >     > # Missing sections will have been created as empty ones
>     when the
>     >     > # configspec was read.
>     >     >
>     >     >
>     >     >
>     >     > Cheers,
>     >     > Arve
>     >     >
>     >     >
>     >    
>     ------------------------------------------------------------------------
>
>     >     >
>     >     >
>     >    
>     -------------------------------------------------------------------------
>     >     > This SF.net email is sponsored by: Microsoft
>     >     > Defy all challenges. Microsoft(R) Visual Studio 2005.
>     >     > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     >     < http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>     >     >
>     >    
>     ------------------------------------------------------------------------
>     >     >
>     >     > _______________________________________________
>     >     > Configobj-develop mailing list
>     >     > Con...@li...
>     <mailto:Con...@li...>
>     >     <mailto: Con...@li...
>     <mailto:Con...@li...>>
>     >     > https://lists.sourceforge.net/lists/listinfo/configobj-develop
>     >     >
>     >
>     >
>     >    
>     -------------------------------------------------------------------------
>     >
>     >     This SF.net email is sponsored by: Microsoft
>     >     Defy all challenges. Microsoft(R) Visual Studio 2005.
>     >     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     >     < http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>     >     _______________________________________________
>     >     Configobj-develop mailing list
>     >     Con...@li...
>     <mailto:Con...@li...>
>     >     <mailto:Con...@li...
>     <mailto:Con...@li...>>
>     >     https://lists.sourceforge.net/lists/listinfo/configobj-develop
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     -------------------------------------------------------------------------
>
>     > This SF.net email is sponsored by: Microsoft
>     > Defy all challenges. Microsoft(R) Visual Studio 2005.
>     > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Configobj-develop mailing list
>     > Con...@li...
>     <mailto:Con...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/configobj-develop
>     >
>
>
>     -------------------------------------------------------------------------
>
>     This SF.net email is sponsored by: Microsoft
>     Defy all challenges. Microsoft(R) Visual Studio 2005.
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>     _______________________________________________
>     Configobj-develop mailing list
>     Con...@li...
>     <mailto:Con...@li...>
>     https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ------------------------------------------------------------------------
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>   

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

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

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

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

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

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

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

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

hello Michael,

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

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

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

cheers,
Stef Mientki

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

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

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

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

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

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

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

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

Michael

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

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

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

hello,

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

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

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

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

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

So I made a workaround, which works ok:

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

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

thanks,
Stef Mientki

Re: [Configobj-develop] [python] Suggestion for improved defaults handling

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

Arve Knudsen wrote:
>
>
> On 1/6/08, *Michael Foord* <fuz...@vo... 
> <mailto:fuz...@vo...>> wrote:
>
>     Hello Arve,
>
>     Thanks for the patch. I have some work to do on ConfigObj so I will
>     include it in that. Any chance you could provide tests and
>     documentation?
>
>
> I will have to look at how ConfigObj does docs/tests, hopefully 
> sometime this week. Do you agree with that there should be a separate 
> method restore_default, instead of restoring the default as part of 
> __delitem__?

Agreed - that sounds better to me. I prefer not to 'proliferate 
methods', but this change in behaviour would be a bit 'too magical'.

Michael
>
> Arve
>
>     Thanks
>
>     Michael
>
>     Arve Knudsen wrote:
>     > Hello
>     >
>     > I found I missed the ability to restore entries to their default
>     value
>     > in ConfigObj, so that you can differentiate between actualy
>     deleting
>     > an entry and just restoring it to the default state. My
>     suggestion is
>     > to track sections' default values with an additional attribute
>     > "default_values", and to add a method "restore_default" for
>     restoring
>     > a particular entry. I also considered restoring default values
>     as part
>     > of __delitem__, but figured this might be too implicit and breaking
>     > backwards compatibility.
>     >
>     > I hope to see this integrated with ConfigObj upstream as I need
>     it in
>     > my own project :_)
>     >
>     > --- configobj.py_orig 2008-01-06 22:33:58.000000000 +0100
>     > +++ configobj.py 2008-01-06 22:34:29.000000000 +0100
>     > @@ -498,7 +498,8 @@
>     > self._cs_section_comments = {}
>     > self._cs_section_inline_comments = {}
>     > # for defaults
>     > - self.defaults = []
>     > + self.defaults = [] # Entries that have their default value
>     > + self.default_values = {} # The original default values
>     > #
>     > # we do this explicitly so that __setitem__ is used properly
>     > # (rather than just passing to ``dict.__init__``)
>     > @@ -751,6 +752,18 @@
>     > else:
>     > self[key] = val
>     > + def restore_default(self, key):
>     > + """
>     > + Restore default value.
>     > +
>     > + If there is no default value for this key, ValueError is raised.
>     > + """
>     > + if key not in self.default_values:
>     > + raise ValueError(key)
>     > + if key not in self.defaults:
>     > + self.defaults.append(key)
>     > + dict.__setitem__(self, key, self.default_values[key])
>     > +
>     > def rename(self, oldkey, newkey):
>     > """
>     > Change a keyname to another, without changing position in sequence.
>     > @@ -2103,6 +2116,7 @@
>     > section[entry] = check
>     > if not copy and missing and entry not in section.defaults :
>     > section.defaults.append(entry)
>     > + section.default_values[entry] = check
>     > #
>     > # Missing sections will have been created as empty ones when the
>     > # configspec was read.
>     >
>     >
>     >
>     > Cheers,
>     > Arve
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     -------------------------------------------------------------------------
>     > This SF.net email is sponsored by: Microsoft
>     > Defy all challenges. Microsoft(R) Visual Studio 2005.
>     > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Configobj-develop mailing list
>     > Con...@li...
>     <mailto:Con...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/configobj-develop
>     >
>
>
>     -------------------------------------------------------------------------
>
>     This SF.net email is sponsored by: Microsoft
>     Defy all challenges. Microsoft(R) Visual Studio 2005.
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>     _______________________________________________
>     Configobj-develop mailing list
>     Con...@li...
>     <mailto:Con...@li...>
>     https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>   

Re: [Configobj-develop] [python] Suggestion for improved defaults handling

[Arve K. <arv...@gm...>]

On 1/6/08, Michael Foord <fuz...@vo...> wrote:
>
> Hello Arve,
>
> Thanks for the patch. I have some work to do on ConfigObj so I will
> include it in that. Any chance you could provide tests and documentation?


I will have to look at how ConfigObj does docs/tests, hopefully sometime
this week. Do you agree with that there should be a separate method
restore_default, instead of restoring the default as part of __delitem__?

Arve

Thanks
>
> Michael
>
> Arve Knudsen wrote:
> > Hello
> >
> > I found I missed the ability to restore entries to their default value
> > in ConfigObj, so that you can differentiate between actualy deleting
> > an entry and just restoring it to the default state. My suggestion is
> > to track sections' default values with an additional attribute
> > "default_values", and to add a method "restore_default" for restoring
> > a particular entry. I also considered restoring default values as part
> > of __delitem__, but figured this might be too implicit and breaking
> > backwards compatibility.
> >
> > I hope to see this integrated with ConfigObj upstream as I need it in
> > my own project :_)
> >
> > --- configobj.py_orig 2008-01-06 22:33:58.000000000 +0100
> > +++ configobj.py 2008-01-06 22:34:29.000000000 +0100
> > @@ -498,7 +498,8 @@
> > self._cs_section_comments = {}
> > self._cs_section_inline_comments = {}
> > # for defaults
> > - self.defaults = []
> > + self.defaults = [] # Entries that have their default value
> > + self.default_values = {} # The original default values
> > #
> > # we do this explicitly so that __setitem__ is used properly
> > # (rather than just passing to ``dict.__init__``)
> > @@ -751,6 +752,18 @@
> > else:
> > self[key] = val
> > + def restore_default(self, key):
> > + """
> > + Restore default value.
> > +
> > + If there is no default value for this key, ValueError is raised.
> > + """
> > + if key not in self.default_values:
> > + raise ValueError(key)
> > + if key not in self.defaults:
> > + self.defaults.append(key)
> > + dict.__setitem__(self, key, self.default_values[key])
> > +
> > def rename(self, oldkey, newkey):
> > """
> > Change a keyname to another, without changing position in sequence.
> > @@ -2103,6 +2116,7 @@
> > section[entry] = check
> > if not copy and missing and entry not in section.defaults:
> > section.defaults.append(entry)
> > + section.default_values[entry] = check
> > #
> > # Missing sections will have been created as empty ones when the
> > # configspec was read.
> >
> >
> >
> > Cheers,
> > Arve
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Configobj-develop mailing list
> > Con...@li...
> > https://lists.sourceforge.net/lists/listinfo/configobj-develop
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

Re: [Configobj-develop] [python] Suggestion for improved defaults handling

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

Hello Arve,

Thanks for the patch. I have some work to do on ConfigObj so I will 
include it in that. Any chance you could provide tests and documentation?

Thanks

Michael

Arve Knudsen wrote:
> Hello
>
> I found I missed the ability to restore entries to their default value 
> in ConfigObj, so that you can differentiate between actualy deleting 
> an entry and just restoring it to the default state. My suggestion is 
> to track sections' default values with an additional attribute 
> "default_values", and to add a method "restore_default" for restoring 
> a particular entry. I also considered restoring default values as part 
> of __delitem__, but figured this might be too implicit and breaking 
> backwards compatibility.
>
> I hope to see this integrated with ConfigObj upstream as I need it in 
> my own project :_)
>
> --- configobj.py_orig 2008-01-06 22:33:58.000000000 +0100
> +++ configobj.py 2008-01-06 22:34:29.000000000 +0100
> @@ -498,7 +498,8 @@
> self._cs_section_comments = {}
> self._cs_section_inline_comments = {}
> # for defaults
> - self.defaults = []
> + self.defaults = [] # Entries that have their default value
> + self.default_values = {} # The original default values
> #
> # we do this explicitly so that __setitem__ is used properly
> # (rather than just passing to ``dict.__init__``)
> @@ -751,6 +752,18 @@
> else:
> self[key] = val
> + def restore_default(self, key):
> + """
> + Restore default value.
> +
> + If there is no default value for this key, ValueError is raised.
> + """
> + if key not in self.default_values:
> + raise ValueError(key)
> + if key not in self.defaults:
> + self.defaults.append(key)
> + dict.__setitem__(self, key, self.default_values[key])
> +
> def rename(self, oldkey, newkey):
> """
> Change a keyname to another, without changing position in sequence.
> @@ -2103,6 +2116,7 @@
> section[entry] = check
> if not copy and missing and entry not in section.defaults:
> section.defaults.append(entry)
> + section.default_values[entry] = check
> #
> # Missing sections will have been created as empty ones when the
> # configspec was read.
>
>
>
> Cheers,
> Arve
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>   

[Configobj-develop] Suggestion for improved defaults handling

[Arve K. <arv...@gm...>]

Hello

I found I missed the ability to restore entries to their default value in
ConfigObj, so that you can differentiate between actualy deleting an entry
and just restoring it to the default state. My suggestion is to track
sections' default values with an additional attribute "default_values", and
to add a method "restore_default" for restoring a particular entry. I also
considered restoring default values as part of __delitem__, but figured this
might be too implicit and breaking backwards compatibility.

I hope to see this integrated with ConfigObj upstream as I need it in my own
project :_)

--- configobj.py_orig 2008-01-06 22:33:58.000000000 +0100
+++ configobj.py 2008-01-06 22:34:29.000000000 +0100
@@ -498,7 +498,8 @@
self._cs_section_comments = {}
self._cs_section_inline_comments = {}
# for defaults
- self.defaults = []
+ self.defaults = [] # Entries that have their default value
+ self.default_values = {} # The original default values
#
# we do this explicitly so that __setitem__ is used properly
# (rather than just passing to ``dict.__init__``)
@@ -751,6 +752,18 @@
else:
self[key] = val
+ def restore_default(self, key):
+ """
+ Restore default value.
+
+ If there is no default value for this key, ValueError is raised.
+ """
+ if key not in self.default_values:
+ raise ValueError(key)
+ if key not in self.defaults:
+ self.defaults.append(key)
+ dict.__setitem__(self, key, self.default_values[key])
+
def rename(self, oldkey, newkey):
"""
Change a keyname to another, without changing position in sequence.
@@ -2103,6 +2116,7 @@
section[entry] = check
if not copy and missing and entry not in section.defaults:
section.defaults.append(entry)
+ section.default_values[entry] = check
#
# Missing sections will have been created as empty ones when the
# configspec was read.



Cheers,
Arve

Re: [Configobj-develop] ConfigObj: inline comments considered harmful

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

Alexander Belchenko wrote:
> Michael Foord пишет:
>> bi...@uk... wrote:
>>> Some one has sent you a message via your contact form. They filled 
>>> in the
>>> following values :
>>>
>>> comment = We are using ConfigObj in Bazaar project and many bzr 
>>> plugins. Recently I discover that your support of inline comments 
>>> can create problems with write and then read back string with '#' 
>>> sign in it.
>>>
>>> E.g. if I save option from my program, e.g.:
>>>
>>> message = bug #123 fixed
>>>
>>> and then I tru to read back config file, I get only 'bug' as value 
>>> of 'message' option.
>>>
>>> It's bad. Any ideas why ConfigObj works in this way?
>>>   
>> In order to allow inline comments that aren't part of the value.
>>
>>> Please, don't tell me that we must escape # signs when we write them 
>>> to config, and unescape when read back. It's ugly.
>>>   
>>
>> You can probably do:
>>
>> message = "bug #123 fixed"
>
> How this possible to do using ConfigObj API?
>

Ah! That's a bug. ConfigObj should put the quotes in for you!

Bugger. That's a fairly serious bug - I wonder why it hasn't been 
reported before.

I'll see how quickly I can get that turned round.

Michael
http://www.manning.com/foord

Re: [Configobj-develop] [python] No newline at the end of file

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

Jeffrey Barish wrote:
> On Tuesday 18 December 2007 09:28:16 Michael Foord wrote:
>   
>> Unless there are any objections I will add code to ensure that files are
>> newline terminated. A side effect is that roundtripped files may gain a
>> newline. Avoiding this would mean storing extra state when reading files
>> and I don't *intend* to jump through those hoops.
>>     
>
> My program will be roundtripping constantly, once I figure out how to 
> implement a reload method.  It would be bad if the configuration file 
> acquired a newline every roundtrip.
>   
The code will only ensure that the file is newline terminated - it won't 
add them merrily with each write...

Michael

Re: [Configobj-develop] [python] No newline at the end of file

[Frederik E. <fre...@we...>]

Am Dienstag, den 18.12.2007, 16:28 +0000 schrieb Michael Foord:
> Well - there are easy ways to add newlines to files. :-)

Right, I just did it like that. :-) I was just wondering if there was a
switch in configobj that I might have missed.

> Newline handling was actually quite tricky as ConfigObj is used to 
> roundtrip files. I also prefer files terminated with a newline but 
> wasn't aware it was part of the POSIX spec.

Well, I wouldn't swear it is, but I read this in a discussion on a 
different list, and I think these definitions back up this oppinion:

Text file
        A file that contains characters organized into one or more
        lines. [...]
Line
        A sequence of zero or more non- <newline>s plus a terminating
        <newline>.

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html

> Unless there are any objections I will add code to ensure that files are 
> newline terminated. A side effect is that roundtripped files may gain a 
> newline. Avoiding this would mean storing extra state when reading files 
> and I don't *intend* to jump through those hoops.

Currently, there is the situation that files might loose a newline. So I
think that it's not worse to have files gain a newline. And I don't
think that applications will have problems with files that end with a
newline, so I'd totally agree that it's not worth the hassle to keep
that information.

Frederik