Thread: [Rest2web-develop] Changed all references to value "tests" into value "checks"...
Brought to you by:
mjfoord
Menu
▾
▴
rest2web-develop
|
From: Nicola L. <ni...@te...> - 2005-07-20 20:57:20
|
...including the main Validator method, and all code tests. Also moved the "import socket, struct" line inside both the dottedQuadToNum and numToDottedQuad functions, and added tests to both of them. Speaking of the latter function, one of the tests allowed me catch a bug in it. I've been using that code for *years* now, I'm still shocked. :-) Repeat after me: doctest, unittest, whatever, but test! ;-) -- Nicola Larosa - ni...@te... When I was growing up, my parents used to say to me, "Tom, finish your dinner - people in China are starving." But after sailing to the edges of the flat world for a year, I am now telling my own daughters, "Girls, finish your homework - people in China and India are starving for your jobs." -- Thomas L. Friedman, New York Times, April 2005 |
|
From: Michael F. <mi...@pc...> - 2005-07-21 08:50:19
|
Nicola Larosa wrote:
> ...including the main Validator method, and all code tests.
>
> Also moved the "import socket, struct" line inside both the dottedQuadToNum
> and numToDottedQuad functions, and added tests to both of them.
>
> Speaking of the latter function, one of the tests allowed me catch a bug in
> it. I've been using that code for *years* now, I'm still shocked. :-)
>
> Repeat after me: doctest, unittest, whatever, but test! ;-)
>
Great. All good.
I've done *some* work on ConfigObj - but not as much as I'd hoped.
Hopefully I'll get a couple of clear hours tonight.
I've fixed a couple of bugs - and uncovered two more, both of which I'm
not sure what to do with.
Only one of them *needs* a resolution now - the other one is minor and
I'll explain later.
It is possible to create new ConfigObjs programatically. Either manually
- or by passing in a dictionary to create the ConfigObj. In both cases
it is possible to create a ConfigObj where the first item is a section.
This means that when you call the ``write`` method the resulting config
file looks like :
[ section ]
key = value
key = value
Which is *invalid* !
My proposed solution is to have the ``write`` method check if the first
value is a section - and write out non-section values first (there may
not be any). This means not obeying sequence though, so it's not ideal.
Best Regards,
Fuzzy
http://www.voidspace.org.uk/python
|
|
From: Nicola L. <ni...@te...> - 2005-07-21 09:12:57
|
> It is possible to create new ConfigObjs programatically. Either manually > - or by passing in a dictionary to create the ConfigObj. In both cases > it is possible to create a ConfigObj where the first item is a section. > This means that when you call the ``write`` method the resulting config > file looks like : > > [ section ] > key = value > key = value > > Which is *invalid* ! > My proposed solution is to have the ``write`` method check if the first > value is a section - and write out non-section values first (there may > not be any). This means not obeying sequence though, so it's not ideal. Something is fishy here. I did not yet look closely at the refactored code, so I'll only speak about concepts. As I understand it, the problem stems from the fact that the ConfigObj instance is a Section itself. Its rendering, though, should implicit, that is, without a section header, and without indenting for contained items, either subsections or scalar values. What I don't get is, what difference does it make what the first item is? All items contained in the ConfigObj instance should be "rendered" to text without indentation, whether they were passed in, or read from a file. So I'd say, no workarounds, let's look closer at what's happening. -- Nicola Larosa - ni...@te... When I was growing up, my parents used to say to me, "Tom, finish your dinner - people in China are starving." But after sailing to the edges of the flat world for a year, I am now telling my own daughters, "Girls, finish your homework - people in China and India are starving for your jobs." -- Thomas L. Friedman, New York Times, April 2005 |
|
From: Michael F. <mi...@pc...> - 2005-07-21 10:33:42
|
Nicola Larosa wrote:
>>It is possible to create new ConfigObjs programatically. Either manually
>>- or by passing in a dictionary to create the ConfigObj. In both cases
>>it is possible to create a ConfigObj where the first item is a section.
>>This means that when you call the ``write`` method the resulting config
>>file looks like :
>>
>> [ section ]
>> key = value
>>key = value
>>
>>Which is *invalid* !
>>My proposed solution is to have the ``write`` method check if the first
>>value is a section - and write out non-section values first (there may
>>not be any). This means not obeying sequence though, so it's not ideal.
>
>
> Something is fishy here. I did not yet look closely at the refactored code,
> so I'll only speak about concepts.
>
> As I understand it, the problem stems from the fact that the ConfigObj
> instance is a Section itself. Its rendering, though, should implicit, that
> is, without a section header, and without indenting for contained items,
> either subsections or scalar values.
>
That won't work either. If you have values, then a section, then more
values - if the section *isn't* indented then there's no way of
indicating that the section has ended.
If that doesn't matter to you (you have no values *after* the section)
then you can *write* the config file without indentation. (ConfigObj
will read it correctly) - but when it writes out it will indent sections.
> What I don't get is, what difference does it make what the first item is?
> All items contained in the ConfigObj instance should be "rendered" to text
> without indentation, whether they were passed in, or read from a file.
>
> So I'd say, no workarounds, let's look closer at what's happening.
>
Part of the problem is that I allowed the root indentation to be non
zero. In other words :
key = value
key2 = value2
[ section ]
key = value
is a valid config file. (Note the uniform indentation for the whole file).
Hmmmm..... but this gives me an idea.
The problem is that the initial indent level is set as ``None``. THe
*initital* indent level is then set to the *first* indent it encounters
: (line 690)
if this_section.indent is None:
this_section.indent = indent_lev
However - if the first item is a section then it shouldn't do that -
because later code might drop *back* an indent level to before that
section. *damn* that means I have to special case it. (Normally stepping
back too far is invalid - and it still can be invalid).
Bah.... I think it's resolvable - but it means a little bit of spaghetti
in the reader to cope with when the first item is an indented section
(so we don't know what level of indent applies to any scalar values in
the root section).
I hope that enough of this makes sense. I think I can sort it out anyway
- but sections still need to be indented by ``write`` as far as I can tell.
Best Regards,
Fuzzy
http://www.voidspace.org.uk/python
|
|
From: Nicola L. <ni...@te...> - 2005-07-21 10:52:51
|
> That won't work either. If you have values, then a section, then more > values - if the section *isn't* indented then there's no way of > indicating that the section has ended. So let's not allow mixing stuff like that (see later). > If that doesn't matter to you (you have no values *after* the section) > then you can *write* the config file without indentation. (ConfigObj > will read it correctly) - but when it writes out it will indent sections. Not good, confusing, inconsistent. [impl. details snipped] > I hope that enough of this makes sense. I think I can sort it out anyway > - but sections still need to be indented by ``write`` as far as I can tell. Please detach from the implementation for a moment, and look at the big picture. Scalar values and (sub)sections at the same level MUST have the same indent, it's too confusing otherwise. There are only two ways to get this, that I can see: 1) introduce a end-of-section header, like ZConfig does; now we're not INI file format compatible anymore. Not good. 2) *only* allow scalar values *before* subsections in each section. Then the end of the section is marked by the beginning of the next (sub)section, or the end of the file. I think that 2) is an acceptable limitation to live with. After all, grouping scalar values before *or* between *or* after sections, without explicitly putting them into real sections, introduces a kind of implicit sections that I don't like at all. Does that grouping have any meaning? Who knows? I find 2) much preferable than having different indents for scalar values and (sub)sections at the same level. Whatever you do, please don't do this. I'm serious. -- Nicola Larosa - ni...@te... When I was growing up, my parents used to say to me, "Tom, finish your dinner - people in China are starving." But after sailing to the edges of the flat world for a year, I am now telling my own daughters, "Girls, finish your homework - people in China and India are starving for your jobs." -- Thomas L. Friedman, New York Times, April 2005 |
|
From: Michael F. <mi...@pc...> - 2005-07-21 11:18:06
|
Nicola Larosa wrote:
[snip..]
>>I hope that enough of this makes sense. I think I can sort it out anyway
>>- but sections still need to be indented by ``write`` as far as I can tell.
>
>
> Please detach from the implementation for a moment, and look at the big
> picture.
>
> Scalar values and (sub)sections at the same level MUST have the same
> indent, it's too confusing otherwise.
>
> There are only two ways to get this, that I can see:
>
> 1) introduce a end-of-section header, like ZConfig does; now we're not
> INI file format compatible anymore. Not good.
>
> 2) *only* allow scalar values *before* subsections in each section. Then
> the end of the section is marked by the beginning of the next
> (sub)section, or the end of the file.
>
> I think that 2) is an acceptable limitation to live with. After all,
> grouping scalar values before *or* between *or* after sections, without
> explicitly putting them into real sections, introduces a kind of implicit
> sections that I don't like at all. Does that grouping have any meaning? Who
> knows?
>
> I find 2) much preferable than having different indents for scalar values
> and (sub)sections at the same level. Whatever you do, please don't do this.
> I'm serious.
>
I think it makes the config files look more confusing. We use
indentation for nesting sections. *so*, you either use what I have done
so far, or you have to indent values *inside* a section.
Mine (a section indented uniformly) :
key = value
key2 = value2
[section]
key = value
key2 = value2
[sub-section]
key = value
key2 = value2
[section2]
key = value
key2 = value2
Yours (values indented differently from their markers) :
key = value
[section]
key = value # if you don't indent here
key2 = value2 # there's no way to distinguish
[sub-section] # this sub-section from section2
key = value
key2 = value2
[section2]
key = value
key2 = value2
In your spec values have to be indented more than their section marker
which is equally confusing. Added to which implementing your spec is
*substantially* harder (for no gain IMHO).
Hmm... this has been then *only* implementation I've done of this (as
shown in the tests) - so it's a long way down the road to start
discussing the basics.
Regards,
Fuzzy
http://www.voidspace.org.uk/python
|
|
From: Nicola L. <ni...@te...> - 2005-07-21 12:24:18
|
> I think it makes the config files look more confusing. We use
> indentation for nesting sections. *so*, you either use what I have done
> so far, or you have to indent values *inside* a section.
>
> Mine (a section indented uniformly) :
>
> key = value
> key2 = value2
> [section]
> key = value
> key2 = value2
> [sub-section]
> key = value
> key2 = value2
>
> [section2]
> key = value
> key2 = value2
Wait a minute, how is this compatible with std INI files? ConfigObj reads
them in flat, then writes them nested, but ConfigParser then keeps reading
them because it doesn't care for indent?
They will *look* different to humans, though, after having passed through
ConfigObj. :-)
> Yours (values indented differently from their markers) :
This is *not* what I was getting at. :-)
> key = value
> [section]
> key = value # if you don't indent here
> key2 = value2 # there's no way to distinguish
> [sub-section] # this sub-section from section2
What do you mean, there's no way?!? The section2 header ends it! Any
(sub)section marker ends any previous (sub) section.
> key = value
> key2 = value2
>
> [section2]
> key = value
> key2 = value2
>
>
> In your spec values have to be indented more than their section marker
> which is equally confusing. Added to which implementing your spec is
> *substantially* harder (for no gain IMHO).
That's not my spec. Here's what I have in mind:
key = value
key2 = value2
[section]
key = value
key2 = value2
# no scalar values allowed here
[sub-section]
key = value
key2 = value2
# no scalar values allowed here
[section2]
key = value
key2 = value2
In summary, starting from your version, I just suggest to dedent everything
one position (except for top level scalar values that are already at column
one, of course).
This looks clearer to me, and if one doesn't use subsections, it is
*identical* to INI config files.
> Hmm... this has been then *only* implementation I've done of this (as
> shown in the tests) - so it's a long way down the road to start
> discussing the basics.
I don't get exactly what you imply by saying this. I wasn't there early on,
sure, but nonetheless I hope it's not too late to try and get the basics right.
--
Nicola Larosa - ni...@te...
When I was growing up, my parents used to say to me, "Tom, finish your
dinner - people in China are starving." But after sailing to the edges
of the flat world for a year, I am now telling my own daughters, "Girls,
finish your homework - people in China and India are starving for your
jobs." -- Thomas L. Friedman, New York Times, April 2005
|
|
From: Michael F. <mi...@pc...> - 2005-07-21 14:45:37
|
Nicola Larosa wrote: >>I think it makes the config files look more confusing. We use >>indentation for nesting sections. *so*, you either use what I have done >>so far, or you have to indent values *inside* a section. >> >>Mine (a section indented uniformly) : >> >>key = value >>key2 = value2 >> [section] >> key = value >> key2 = value2 >> [sub-section] >> key = value >> key2 = value2 >> >> [section2] >> key = value >> key2 = value2 > > > Wait a minute, how is this compatible with std INI files? ConfigObj reads > them in flat, then writes them nested, but ConfigParser then keeps reading > them because it doesn't care for indent? > Hmmm... good point. Although ConfigObj (as it stands) will read standard section files - but it probably does change them when it writes them out. > They will *look* different to humans, though, after having passed through > ConfigObj. :-) > > > >>Yours (values indented differently from their markers) : > > > This is *not* what I was getting at. :-) > [snip..] > That's not my spec. Here's what I have in mind: > > key = value > key2 = value2 > > [section] > key = value > key2 = value2 > > # no scalar values allowed here > > [sub-section] > key = value > key2 = value2 > > # no scalar values allowed here > > [section2] > key = value > key2 = value2 > > In summary, starting from your version, I just suggest to dedent everything > one position (except for top level scalar values that are already at column > one, of course). > > This looks clearer to me, and if one doesn't use subsections, it is > *identical* to INI config files. > Ok - so we just special case the top level and restrict scalars to before any sections. That's not so bad :-) Should Section.__setitem__ raise an error if you attempt this, (bearing in mind that normally a new addition would be appended to the end of sequence) - or should it just put the values in the right place. I guess the second option is the right one. This means the ``write`` method needs to check all the members and write out the scalars first. *sigh* (This means it no longer necessarily obeys ``sequence``). > > >>Hmm... this has been then *only* implementation I've done of this (as >>shown in the tests) - so it's a long way down the road to start >>discussing the basics. > > > I don't get exactly what you imply by saying this. I wasn't there early on, > sure, but nonetheless I hope it's not too late to try and get the basics right. > > Au contraire my friend - I only started writing ConfigObj 4 on your promptings - so you *have* been here from the start. Which is why I'm surprised this didn't come up before.... Anyway - think I can sort it. Best Regards, Fuzzy http://www.voidspace.org.uk/python |
|
From: Nicola L. <ni...@te...> - 2005-07-21 15:03:26
|
> Ok - so we just special case the top level and restrict scalars to > before any sections. That's not so bad :-) > > Should Section.__setitem__ raise an error if you attempt this, (bearing > in mind that normally a new addition would be appended to the end of > sequence) - or should it just put the values in the right place. > > I guess the second option is the right one. Yes, it would be too restrictive to stop the user from adding scalars altogether once a section has been added. > This means the ``write`` > method needs to check all the members and write out the scalars first. > *sigh* Or else you could have two sequences, one for scalars and one for subsections. Or maybe even an automatic "__scalars__" subsection that's always first, and the scalars go in there. > (This means it no longer necessarily obeys ``sequence``). It obeys order of scalars, and order of subsections, but all scalars always come before all subsections, that's the only exception. > Au contraire my friend - I only started writing ConfigObj 4 on your > promptings - so you *have* been here from the start. Ah, ok, I thought you were referring to previous versions of ConfigObj. > Which is why I'm surprised this didn't come up before... Assumptions, assumptions... ;-) > Anyway - think I can sort it. Glad to hear that. :-) -- Nicola Larosa - ni...@te... When I was growing up, my parents used to say to me, "Tom, finish your dinner - people in China are starving." But after sailing to the edges of the flat world for a year, I am now telling my own daughters, "Girls, finish your homework - people in China and India are starving for your jobs." -- Thomas L. Friedman, New York Times, April 2005 |
|
From: Michael F. <mi...@pc...> - 2005-07-21 15:17:06
|
Nicola Larosa wrote: >>Ok - so we just special case the top level and restrict scalars to >>before any sections. That's not so bad :-) [snip..] >>This means the ``write`` >>method needs to check all the members and write out the scalars first. >>*sigh* > > > Or else you could have two sequences, one for scalars and one for > subsections. Or maybe even an automatic "__scalars__" subsection that's > always first, and the scalars go in there. > Just a quick reply. I prefer to keep the section itself undivided and have two sequence attributes. Maybe ``scalars`` and ``sections`` lists ? Regards, Fuzzy http://www.voidspace.org.uk/python > > >>(This means it no longer necessarily obeys ``sequence``). > > > It obeys order of scalars, and order of subsections, but all scalars always > come before all subsections, that's the only exception. > > > >>Au contraire my friend - I only started writing ConfigObj 4 on your >>promptings - so you *have* been here from the start. > > > Ah, ok, I thought you were referring to previous versions of ConfigObj. > > > >>Which is why I'm surprised this didn't come up before... > > > Assumptions, assumptions... ;-) > > > >>Anyway - think I can sort it. > > > Glad to hear that. :-) > > |
|
From: Nicola L. <ni...@te...> - 2005-07-21 15:30:22
|
> I prefer to keep the section itself undivided and have two sequence > attributes. Maybe ``scalars`` and ``sections`` lists ? Yes, that's probably the clearest. -- Nicola Larosa - ni...@te... When I was growing up, my parents used to say to me, "Tom, finish your dinner - people in China are starving." But after sailing to the edges of the flat world for a year, I am now telling my own daughters, "Girls, finish your homework - people in China and India are starving for your jobs." -- Thomas L. Friedman, New York Times, April 2005 |
|
From: Nicola L. <ni...@te...> - 2005-07-22 08:29:56
|
This will probaby seem completely nuts to you, but please bear with me,
I'll try to be concise, *and* offer you a way out of Config Obj *now*. :-D
> I think it makes the config files look more confusing. We use
> indentation for nesting sections. *so*, you either use what I have done
> so far, or you have to indent values *inside* a section.
>
> Mine (a section indented uniformly) :
>
> key = value
> key2 = value2
> [section]
> key = value
> key2 = value2
> [sub-section]
> key = value
> key2 = value2
>
> [section2]
> key = value
> key2 = value2
>
> Yours (values indented differently from their markers) :
>
> key = value
> [section]
> key = value # if you don't indent here
> key2 = value2 # there's no way to distinguish
> [sub-section] # this sub-section from section2
> key = value
> key2 = value2
>
> [section2]
> key = value
> key2 = value2
>
> In your spec values have to be indented more than their section marker
> which is equally confusing. Added to which implementing your spec is
> *substantially* harder (for no gain IMHO).
I beg your pardon in advance. I know you spent much time implementing your
style, and then even changed it according to what I asked you (not the
above). But what I'm proposing could substantially improve ConfigObj
adoption chances, and simplify the code to boot.
Thing is, I thought about it, and the only comment I could come up with,
about what I replied to this mail of yours, is: "What was I thinking?!?"
What I asked you, and you already implemented (not shown above) is
inconsistent and arbitrary. What you instead understood, and wrote above,
of what I asked, is how things are usually written in an XML file, and in
ZConfig pseudo-XML config format too. It *is* probably the best way...
...but maybe all of this is moot. I keep believing that using indentation
in config files is a mistake, and I'm going to suggest a way to avoid it.
Remember, config files have to go into the hands of not-completely-human
beings called "sysadmins". ;-) You can be sure that most of them are
*horrified* by the prospect of significant indentation (that's true even of
most programmers that have not yet Seen the Light ;-) ). I really think we
should leave them free to indent their config files, or not, as they well
damn please. I believe that this would be a significant, and unnecessary,
barrier to the future adoption of ConfigObj.
Let's now suppose instead that indentation is not significant: we still
have the problem to signal that a subsection is nested inside the previous
one. The XML, and ZConfig, way is to have a section closing marker: it
is ugly, unnecessary, and incompatible with straight INI files.
A better way, I think, is to have an absolute level indicator in the
section marker itself. The marker should be absent at the outer level, to
keep compatibility with INI files, and should appear at inner levels. It
could be a digit, or a number of asterisks, but maybe the simplest and most
obvious thing is to multiply the square brackets, their number showing the
absolut nesting level:
key = value
[level 1]
key = value
[[level 2]]
key = value
[[level 2]]
key = value
[[[level 3]]]
key = value
[level 1]
key = value
Obviously it would be illegal to have a level 3 subsection directly nested
inside a level one section.
We could have an indented-write flag, so that the user could choose to
write out the config file in an indented shape:
key = value
[level 1]
key = value
[[level 2]]
key = value
[[level 2]]
key = value
[[[level 3]]]
key = value
[level 1]
key = value
That would be for humans eyes only, the program would recognize any shape,
since indentantion is not significant anymore.
Again, I understand this means many changes to the code; I hope that it
would also allow one to throw away a good portion of it, and that's akways
a good thing. :-)
I'll make you a deal: if you agree about the above, but are horrified by
the work needed to implement it, I propose that you *stop* working on
ConfigObj right now, and let *me* implement the needed changes, under your
direct control and supervision of each issue as it comes up, obviously. In
the meantime, you could go back to work on rets2web, or whatever is waiting
for your attention.
Once I complete the rewriting, you would step back in, add the still
missing features, wrap it all up and release it into the world. :-)
I know it takes a good deal of trusting, but I would ask you for any
structural change I'd make, and you have control of the repository anyway,
so what have you got to lose? :-)
--
Nicola Larosa - ni...@te...
When I was growing up, my parents used to say to me, "Tom, finish your
dinner - people in China are starving." But after sailing to the edges
of the flat world for a year, I am now telling my own daughters, "Girls,
finish your homework - people in China and India are starving for your
jobs." -- Thomas L. Friedman, New York Times, April 2005
|
|
From: Michael F. <mi...@pc...> - 2005-07-22 10:13:04
|
Nicola Larosa wrote: > This will probaby seem completely nuts to you, but please bear with me, > I'll try to be concise, *and* offer you a way out of Config Obj *now*. :-D > > > >>I think it makes the config files look more confusing. We use >>indentation for nesting sections. *so*, you either use what I have done >>so far, or you have to indent values *inside* a section. >> >>Mine (a section indented uniformly) : >> >>key = value >>key2 = value2 >> [section] >> key = value >> key2 = value2 >> [sub-section] >> key = value >> key2 = value2 >> >> [section2] >> key = value >> key2 = value2 >> >>Yours (values indented differently from their markers) : >> >>key = value >>[section] >> key = value # if you don't indent here >> key2 = value2 # there's no way to distinguish >> [sub-section] # this sub-section from section2 >> key = value >> key2 = value2 >> >>[section2] >> key = value >> key2 = value2 >> >>In your spec values have to be indented more than their section marker >>which is equally confusing. Added to which implementing your spec is >>*substantially* harder (for no gain IMHO). > > > I beg your pardon in advance. I know you spent much time implementing your > style, and then even changed it according to what I asked you (not the > above). But what I'm proposing could substantially improve ConfigObj > adoption chances, and simplify the code to boot. > > Thing is, I thought about it, and the only comment I could come up with, > about what I replied to this mail of yours, is: "What was I thinking?!?" > What I asked you, and you already implemented (not shown above) is > inconsistent and arbitrary. What you instead understood, and wrote above, > of what I asked, is how things are usually written in an XML file, and in > ZConfig pseudo-XML config format too. It *is* probably the best way... > > > ...but maybe all of this is moot. I keep believing that using indentation > in config files is a mistake, and I'm going to suggest a way to avoid it. > > > Remember, config files have to go into the hands of not-completely-human > beings called "sysadmins". ;-) You can be sure that most of them are > *horrified* by the prospect of significant indentation (that's true even of > most programmers that have not yet Seen the Light ;-) ). I really think we > should leave them free to indent their config files, or not, as they well > damn please. I believe that this would be a significant, and unnecessary, > barrier to the future adoption of ConfigObj. > > Let's now suppose instead that indentation is not significant: we still > have the problem to signal that a subsection is nested inside the previous > one. The XML, and ZConfig, way is to have a section closing marker: it > is ugly, unnecessary, and incompatible with straight INI files. > > A better way, I think, is to have an absolute level indicator in the > section marker itself. The marker should be absent at the outer level, to > keep compatibility with INI files, and should appear at inner levels. It > could be a digit, or a number of asterisks, but maybe the simplest and most > obvious thing is to multiply the square brackets, their number showing the > absolut nesting level: > > key = value > > [level 1] > key = value > > [[level 2]] > key = value > > [[level 2]] > key = value > > [[[level 3]]] > key = value > > [level 1] > key = value > > Obviously it would be illegal to have a level 3 subsection directly nested > inside a level one section. > > We could have an indented-write flag, so that the user could choose to > write out the config file in an indented shape: > > key = value > > [level 1] > key = value > > [[level 2]] > key = value > > [[level 2]] > key = value > > [[[level 3]]] > key = value > > [level 1] > key = value > > That would be for humans eyes only, the program would recognize any shape, > since indentantion is not significant anymore. > > > Again, I understand this means many changes to the code; I hope that it > would also allow one to throw away a good portion of it, and that's akways > a good thing. :-) > > I'll make you a deal: if you agree about the above, but are horrified by > the work needed to implement it, I propose that you *stop* working on > ConfigObj right now, and let *me* implement the needed changes, under your > direct control and supervision of each issue as it comes up, obviously. In > the meantime, you could go back to work on rets2web, or whatever is waiting > for your attention. > > Once I complete the rewriting, you would step back in, add the still > missing features, wrap it all up and release it into the world. :-) > > I know it takes a good deal of trusting, but I would ask you for any > structural change I'd make, and you have control of the repository anyway, > so what have you got to lose? :-) > > Hmmm... There wouldn't *need* to be many structural changes if you can resist tinkering with the parts that don't need changing ! Will you *preserve* the indentation used in the config file ? I've done a bit of browsing on the subject of nested hierarchies. There's not a lot of consensus on the subject - and some of the suggested alternatives are 'orrible. Hmmm... your suggestion is less bad than other possibilities I suppose, less extra markup than XML. Ok if you must I suppose is the answer. Converting sys admins to normal sanity is a better option though.... Markup by indentation is *good*. Regards, Fuzz http://www.voidspace.org.uk/python |
|
From: Nicola L. <ni...@te...> - 2005-07-22 10:39:20
|
> Hmmm... There wouldn't *need* to be many structural changes if you can > resist tinkering with the parts that don't need changing ! That's great news. Yes, I think I maybe could exercise some degree of restraint, sometimes. ;-) > Will you *preserve* the indentation used in the config file ? No, I won't. :-) Think about it: do you get to decide what kind of indentation Python uses? You don't. Since indentation is not even significant here, why should we go to great lengths to parse and retain it? We'll give the user the option to have the file indented when written, and maybe *even* give the choice between one tab and four spaces, but that's it. The written layout will always be the same, consistent one (if any). > I've done a bit of browsing on the subject of nested hierarchies. > There's not a lot of consensus on the subject - and some of the > suggested alternatives are 'orrible. > > Hmmm... your suggestion is less bad than other possibilities I suppose, > less extra markup than XML. Glad to hear that. :-) > Ok if you must I suppose is the answer. Ehi, take the enthusiasm down a few notches! ;-P > Converting sys admins to normal sanity is a better option though... Who's being religious now? :-) Do you want to convert the very few, or build a tool that will be used by many? Remember, we're not talking about a way of life, like the choice of a programming language would be. It's just a config file format, for some deity's sake. We're even giving those fundamentalist Python programmers (you know who you are ;-D ) a way to partially force indentantion on their users (write-only), what more do you want? And *I* am the one go often gets to be called "fundamentalist" (not only by you, mind you), sheesh. ;-) > Markup by indentation is *good*. Then go and hack on PyYaml, what are you doing here? ;-P Seriously, I personally agree with you, I like it too. But in this case it's just something more to care for, something more one has to think about. Sysadmins actually *thinking*?!? The mind boggles... ;-D Now, to confirm your agreement once and for all, please stand up and say loudly, three times, the following: "I won't touch configobj.py anymore, until Nicola is finished or world's end, whichever comes first." Then sign on the dotted line below with your own blood, thank you very much. -- Nicola Larosa - ni...@te... When I was growing up, my parents used to say to me, "Tom, finish your dinner - people in China are starving." But after sailing to the edges of the flat world for a year, I am now telling my own daughters, "Girls, finish your homework - people in China and India are starving for your jobs." -- Thomas L. Friedman, New York Times, April 2005 |
|
From: Michael F. <mi...@pc...> - 2005-07-22 08:38:48
|
Nicola Larosa wrote:
[snip..]
>
> Scalar values and (sub)sections at the same level MUST have the same
> indent, it's too confusing otherwise.
>
> There are only two ways to get this, that I can see:
>
> 1) introduce a end-of-section header, like ZConfig does; now we're not
> INI file format compatible anymore. Not good.
>
> 2) *only* allow scalar values *before* subsections in each section. Then
> the end of the section is marked by the beginning of the next
> (sub)section, or the end of the file.
>
> I think that 2) is an acceptable limitation to live with. After all,
> grouping scalar values before *or* between *or* after sections, without
> explicitly putting them into real sections, introduces a kind of implicit
> sections that I don't like at all. Does that grouping have any meaning? Who
> knows?
>
> I find 2) much preferable than having different indents for scalar values
> and (sub)sections at the same level. Whatever you do, please don't do this.
> I'm serious.
>
Sorry to harp on about this - but I'm not *convinced* that the
implementation is yet right. I *hope* it is.
The current rule is basically :
A new section must be indented relative to it's parent section.
Sections in the root section aren't indented (since they don't have a
parent).
Scalar values must come before sub-sections.
This means config files look like :
key = value
key2 = value2
[ section ]
key = value
key2 = value2
[sub-section]
key = value
key2 = value2
[ section 2 ]
key = value
key2 = value2
[sub-section]
key = value
key2 = value2
*But* - in 'section', 'sub-section' is as the same level as 'key' and
'key2'.
Is that ok ?
Best Regards,
Fuzzy
http://www.voidspace.org.uk/python
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X