rest2web-develop

[Rest2web-develop] Down with writein

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

Hello Nico,

I've decided to scrap the writein method for ConfigObj - and instead preserve comments above keywords.

I intend to preserve inline comments as well - so each Section will have an ``inline_comments`` and a ``comments`` dictionary attached. Each member of ``comments`` will be a *list* of comment lines. I can do this with minor changes to the current implementation.

The file format will look like :

# initial_comment
# preserved

# lost

# preserved with section marker
[section] # also preserved
# lost

# preserved with key
Key = value # also preserved
# lost

# final_comment
# preserved


What do you think ?

Re: [Rest2web-develop] Down with writein

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

> I've decided to scrap the writein method for ConfigObj - and instead
> preserve comments above keywords.
> 
> I intend to preserve inline comments as well - so each Section will have
> an ``inline_comments`` and a ``comments`` dictionary attached. Each
> member of ``comments`` will be a *list* of comment lines. I can do this
> with minor changes to the current implementation.
> 
> The file format will look like :
> 
> # initial_comment
> # preserved
> 
> # lost
> 
> # preserved with section marker
> [section] # also preserved
> # lost
> 
> # preserved with key
> Key = value # also preserved
> # lost
> 
> # final_comment
> # preserved
> 
> 
> What do you think ?

I think that's great. I didn't quite like the idea of interspersing changes
in an already existing file. This way, the user does not have to worry
which write method has to be used.

The loss of isolated comment lines is unfortunate, and seems a rather
arbitrary thing to do, from the user point of view. But these drawbacks are
surely minor, and the gained simplicity is worth them. Maybe they could be
alleviated by emitting some kind of warning during file parsing.

-- 
Nicola Larosa - ni...@te...

If there are a few shark attacks in Florida - and a graphic movie -
suddenly every swimmer is worried. More people are killed every year by
pigs than by sharks, which shows you how good we are at evaluating risk.
 -- Bruce Schneier, May 2005

Re: [Rest2web-develop] Down with writein

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

Nicola Larosa wrote:
>>I've decided to scrap the writein method for ConfigObj - and instead
>>preserve comments above keywords.
>>
>>I intend to preserve inline comments as well - so each Section will have
>>an ``inline_comments`` and a ``comments`` dictionary attached. Each
>>member of ``comments`` will be a *list* of comment lines. I can do this
>>with minor changes to the current implementation.
>>
>>The file format will look like :
>>
>># initial_comment
>># preserved
>>
>># lost
>>
>># preserved with section marker
>>[section] # also preserved
>># lost
>>
>># preserved with key
>>Key = value # also preserved
>># lost
>>
>># final_comment
>># preserved
>>
>>
>>What do you think ?
> 
> 
> I think that's great. I didn't quite like the idea of interspersing changes
> in an already existing file. This way, the user does not have to worry
> which write method has to be used.
> 

The main use case was to allow the creation of a ConfigObj that
represented part of a file. It meant making an arbitrary decision about
what to do if the ConfigObj was changed (the keys in the object no
longer match the keys in the file). On the basis of YAGNI I figured I
could lose it...

> The loss of isolated comment lines is unfortunate, and seems a rather
> arbitrary thing to do, from the user point of view. But these drawbacks are
> surely minor, and the gained simplicity is worth them. Maybe they could be
> alleviated by emitting some kind of warning during file parsing.
> 

The implementation is easy because we already keep track of comment
lines for final_comment and initial_comment.

The current version keeps all empty lines and comment lines. I was
intending it to only keep continuous comment lines. (Hard to explain).

Current implementation for initial_comment (needs extending) :

# kept

# kept as well
key = value

My suggested implementation :

# dropped

# kept
key = value


Would you prefer it if I just kept all comments, even if separated by
blank lines ?
I thought this could end up associating comments with the wrong value.
As a side effect it means that there is no way of providing a comment
for the *first* key/section. It will all be swallowed up by initial_comment.

Which way should I jump ?

All the best,

Fuzzy
http://www.voidspace.org.uk/python

Re: [Rest2web-develop] Down with writein

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

> The main use case was to allow the creation of a ConfigObj that
> represented part of a file. It meant making an arbitrary decision about
> what to do if the ConfigObj was changed (the keys in the object no
> longer match the keys in the file). On the basis of YAGNI I figured I
> could lose it...

Go ahead, lighter is better. ;-)


> Would you prefer it if I just kept all comments, even if separated by
> blank lines ?

Yes. :-) Best if you could keep blank lines too. :-D


> I thought this could end up associating comments with the wrong value.
> As a side effect it means that there is no way of providing a comment
> for the *first* key/section. It will all be swallowed up by initial_comment.

Why don't you do away with the notions of initial_comment, final_comment,
and associating comments with config items, and instead keep all non-data
lines just as they are?

You could do this by using a third sequence, say "self.comments", and
interleaving its elements with self.scalars and self.sections somehow.

-- 
Nicola Larosa - ni...@te...

If there are a few shark attacks in Florida - and a graphic movie -
suddenly every swimmer is worried. More people are killed every year by
pigs than by sharks, which shows you how good we are at evaluating risk.
 -- Bruce Schneier, May 2005

Re: [Rest2web-develop] Down with writein

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

Nicola Larosa wrote:
[snip..]
>>I thought this could end up associating comments with the wrong value.
>>As a side effect it means that there is no way of providing a comment
>>for the *first* key/section. It will all be swallowed up by initial_comment.
> 
> 
> Why don't you do away with the notions of initial_comment, final_comment,
> and associating comments with config items, and instead keep all non-data
> lines just as they are?
> 
> You could do this by using a third sequence, say "self.comments", and
> interleaving its elements with self.scalars and self.sections somehow.
> 

Part of the point is that the comments *are* associated with the config
items. That way if you're constructing config files programattically,
you can say - this comment belongs with this value.

If you don't care about the association (or how it's done internally) -
then the current implementation 'just works'.

Interleaving comments and the other values sounds like a nightmare !

Best Regards,

Fuzzy
http://www.voidspace.org.uk/python

Re: [Rest2web-develop] Down with writein

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

> Part of the point is that the comments *are* associated with the config
> items. That way if you're constructing config files programattically,
> you can say - this comment belongs with this value.

You're right, I wasn't keeping that in mind.


> If you don't care about the association (or how it's done internally) -
> then the current implementation 'just works'.

Yes.


> Interleaving comments and the other values sounds like a nightmare !

Probably it's not simple, and gives little gain over what you already did,
so let's just forget about it. :-)

-- 
Nicola Larosa - ni...@te...

If there are a few shark attacks in Florida - and a graphic movie -
suddenly every swimmer is worried. More people are killed every year by
pigs than by sharks, which shows you how good we are at evaluating risk.
 -- Bruce Schneier, May 2005