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