rest2web-develop

Re: [Rest2web-develop] Last Commit

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

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 04/08/05 17:16:54
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] Last Commit
   >
   >> I've improved ConfigObjError - it now has
   >> line number, message, and line attributes. This means that the
   >> ``errors`` list you get in the case of multiple errors is just a
   >> list of errors - not a list of tuples !
   >> 
   >> The comments test also passes again.
   >
   >Great work.
   >
   >
   >> Final commit until Monday. ... I *might* get  enough time to finish
   >> ConfigObj and work on cleaning up the docs. We can then do an alpha
   >> release.
   >
   >I was hoping I got the chance to hack on it a bit this weekend, but looks
   >like you want to keep that option open for yourself.
   >

Hmmm... Well I want to get validate working as a Section attribute rather than an attribute just on ConfigObj - but I can restrict myself to that. That should make it easy to merge changes.

Oh yes, and the two Interpolation errors need to inherit from a single ``InterpolationError`` base class.  Should this be a subclass of ConfigObError ?

My other priority is the docs - so I promise to leave the rest of ConfigObj alone.... (or clear up the mess afterwards myself).

   >Oh well, at the very least I'll try using it to substitute ZConfig in my
   >job's main app, that should be a good usage test. I'll let you know.
   >

That would be very good - probably the best way of uncovering those lurking bugs.

I'm deleting ConfigObj 3 from my path and *forcing* all my scripts and programs to use the new version....

Regards,

Fuzz

   >-- 
   >Nicola Larosa - ni...@te...
   >
   >One of the things I routinely tell people is that if it's in the news,
   >don't worry about it. By definition, "news" means that it hardly ever
   >
   >

[Message truncated. Tap Edit->Mark for Download to get remaining portion.]

Re: [Rest2web-develop] Last Commit

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

Hello Nicola,

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 07/08/05 19:21:19
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] Last Commit
   >
   >Some work done this weekend. I'll refer a few times to ZConfig, please bear
   >with me. ;-)
   >
   >First, I committed the files from your email.
   >
   >Then I fixed the doctests for both configobj.py and validate.py to make
   >them work on Python 2.2.3 . I even tried Python 2.1.3, but it would have
   >taken too many changes, so I dropped it. Only one test, for validate.py,
   >still fails on 2.2.3, for trivial reasons.
   >

Cool - nice one.

   >Finally I converted a rather elaborate config file from ZConfig format to
   >Configobj. All is well as far as values go, but I have two non-trivial
   >problems with validation.
   >
   >The first one: there is no default value. There should be a way to check a
   >param's value, when it is set in the config file, or else to fill in a
   >default value when it is not. As it is, one may leave the configspec empty,
   >meaning that the value may not be present: alas, by doing so one loses any
   >check on the value, and there's no default value anyway.
   >

Easy - allow all the functions to take a keyword argument 'default'. Amend ConfigObj so that instead of automatically failing missing values it calls the tests with a 'missing=True' keyword.

The test function can then decide if being missing is an automatic fail. If a default is available - then it's not.

We *may* run into trouble with quotes in default values here, as we're using ConfigObj to parse the configspec. If it is a problem we'll work on a special mode for ConfigObj when parsing the configspec.

   >This default value business is very handy, because it allows to specify, in
   >the config file, just the values that differ from the defaults.
   >

So in the configspec :

Key =  integer

Would fail if key is missing. Whereas :

Key = integer(default=3)

Would substitute 3 for missing values.

*However* - this would cause the default value to be written out by the ``write`` method. (Unless we create a new private Section attribute for 'defaults' that aren't written out unless they get set from outside the ConfigObj).


   >The second problem is deeper: the configspec is monolitic, and I need it to
   >be modular. That is, some sections contain a number of homogeneous
   >subsections, and there's no way to know beforehand how many they will be.
   >They should reuse the same configspec, so should be somehow declared of a
   >certain "type", and validation should have a way to pick the right
   >configspec fragment.
   >
   >This may be related to what you wrote:
   >
   >> Hmmm... Well I want to get validate working as a Section attribute rather
   >> than an attribute just on ConfigObj...
   >

In the version you now have, the configspec is a Section attribute - a dictionary of tests for that section.

   >ZConfig does this by reusing section types in "multisections". Probably we
   >could do something similar by validating the configspec for Sections, and
   >then composing them in the complete configspec for the ConfigObj.
   >

You can already manually add them to a Section. You could add syntax to the configspec for naming and repeating them...

   >By the way, maybe you could give a look to the ZConfig doc PDF, if you
   >didn't already. There may be some good ideas in there, amidst all the
   >formality ;-) :
   >
   >http://svn.zope.org/*checkout*/ZConfig/trunk/doc/zconfig.pdf?rev=30398
I will do.

   >
   >If we can solve these two problems, I think we can set the Configobj status
   >straight to "beta", from my POV at least. ;-)
   >

Cool. Let me know your response to my suggestion. It only means using the existing syntax of validate.py - using keyword arguments (so only changing the functions). I wonder if it is too clumsy for you though ?

Regards,


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

   >-- 
   >Nicola Larosa - ni...@te...
   >
   >Abstraction is layering ignorance on top of reality.
   > -- rpg, cited by Richard P. Gabriel, November 2002
   >
   >
   >
   >
   >-------------------------------------------------------
   >SF.Net email is Sponsored by the Better Software Conference & EXPO
   >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
   >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
   >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
   >_______________________________________________
   >Rest2web-develop mailing list
   >Res...@li...
   >https://lists.sourceforge.net/lists/listinfo/rest2web-develop
   >
   >

Re: [Rest2web-develop] Last Commit

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

>> The first one: there is no default value. There should be a way to check
>> a param's value, when it is set in the config file, or else to fill in a
>> default value when it is not. As it is, one may leave the configspec
>> empty, meaning that the value may not be present: alas, by doing so one
>> loses any check on the value, and there's no default value anyway.

> Easy - allow all the functions to take a keyword argument 'default'.
> Amend ConfigObj so that instead of automatically failing missing values
> it calls the tests with a 'missing=True' keyword.
>
> The test function can then decide if being missing is an automatic fail.
> If a default is available - then it's not.

It sounds easy enough, I'll try it.


> We *may* run into trouble with quotes in default values here, as we're
> using ConfigObj to parse the configspec. If it is a problem we'll work on
> a special mode for ConfigObj when parsing the configspec.

A few tests will highlight any problems.


>> This default value business is very handy, because it allows to specify,
>> in the config file, just the values that differ from the defaults.

> So in the configspec :
> 
> Key =  integer
> 
> Would fail if key is missing. Whereas :
> 
> Key = integer(default=3)
> 
> Would substitute 3 for missing values.
> 
> *However* - this would cause the default value to be written out by the
> ``write`` method.

That's what my ZConfig extension currently does, and it's quite ungainly.


> (Unless we create a new private Section attribute for
> 'defaults' that aren't written out unless they get set from outside the
> ConfigObj).

It would be great to carry the defaults around, and only write values to
file when they are different from the defaults. This only applies to
scalars, not to sections, obviously.


>> The second problem is deeper: the configspec is monolitic, and I need
>> it to be modular. That is, some sections contain a number of
>> homogeneous subsections, and there's no way to know beforehand how many
>> they will be. They should reuse the same configspec, so should be
>> somehow declared of a certain "type", and validation should have a way
>> to pick the right configspec fragment.
>>
>> This may be related to what you wrote:
>>
>>> Hmmm... Well I want to get validate working as a Section attribute
>>> rather than an attribute just on ConfigObj...

> In the version you now have, the configspec is a Section attribute - a
> dictionary of tests for that section.

So I can already reuse the same configspec to instantiate a Section, and
attach it to a ConfigObj? Cool.


>> ZConfig does this by reusing section types in "multisections". Probably
>> we could do something similar by validating the configspec for
>> Sections, and then composing them in the complete configspec for the
>> ConfigObj.

> You can already manually add them to a Section. You could add syntax to
> the configspec for naming and repeating them...

I'll try that.


>> If we can solve these two problems, I think we can set the Configobj
>> status straight to "beta", from my POV at least. ;-)

> Cool. Let me know your response to my suggestion. It only means using
> the existing syntax of validate.py - using keyword arguments (so only
> changing the functions). I wonder if it is too clumsy for you though ?

Not at all, I find it convenient enough, and "explicit is better than
implicit" anyway. :-)

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

Abstraction is layering ignorance on top of reality.
 -- rpg, cited by Richard P. Gabriel, November 2002

Re: [Rest2web-develop] Last Commit

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

Hello Nicola,

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 07/08/05 22:29:33
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] Last Commit
     >>> The first one: there is no default value. There should be a way to check
   >>> a param's value, when it is set in the config file, or else to fill in a
   >>> default value when it is not. As it is, one may leave the configspec
   >>> empty, meaning that the value may not be present: alas, by doing so one
   >>> loses any check on the value, and there's no default value anyway.
   >
   >> Easy - allow all the functions to take a keyword argument 'default'.
   >> Amend ConfigObj so that instead of automatically failing missing values
   >> it calls the tests with a 'missing=True' keyword.
   >>
   >> The test function can then decide if being missing is an automatic fail.
   >> If a default is available - then it's not.
   >
   >It sounds easy enough, I'll try it.
   >

Cool - you can implement the whole thing.
In ConfigObj.validate it currently *automatically* fails missing keys. Parsing the configspec will automatically create missing sections already (but they'llmbe empty).

Instead it should now merely pass a ``missing=True`` keyword to validate.check and ``None`` as the value. 

In Validator.check - if missing = True and no default keyword is supplied in the configspec - then an Exception should be raised (check fails).

Otherwise the default should be passed to the check function instead.

Create a  new section attribute ``_defaults``.  If a test passes where a value was missing (so the default was used) ConfigObj.validate should add the key to ``_defaults``. Section.__setitem__ should remove a key from ``_defaults`` if the key is altered other than by the validate method.

``write`` should then not write out keys in the ``_defaults`` list. Easy hey :-)

You still end up writing section markers for empty sections though.

[snip..]
    >>>> Hmmm... Well I want to get validate working as a Section attribute
   >>>> rather than an attribute just on ConfigObj...
   >
   >> In the version you now have, the configspec is a Section attribute - a
   >> dictionary of tests for that section.
   >
   >So I can already reuse the same configspec to instantiate a Section, and
   >attach it to a ConfigObj? Cool.
   >

Hmm.. Not quite I don't think. You can do :

c = ConfigObj(filename)
#
# suppose configspec is a dictionary of checks
c['section'] = {}
c['section'].configspec = configspec
c['section2'] = {}
c['section2'].configspec = configspec

Which is nearly what you said ?

Best Regards, 


Fuzzyman 
http://www.voidspace.org.uk/python 
   >-------------------------------------------------------
   >SF.Net email is Sponsored by the Better Software Conference & EXPO
   >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
   >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
   >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
   >_______________________________________________
   >Rest2web-develop mailing list
   >Res...@li...
   >https://lists.sourceforge.net/lists/listinfo/rest2web-develop
   >
   >
   >

Re: [Rest2web-develop] Last Commit

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

Some work done this weekend. I'll refer a few times to ZConfig, please bear
with me. ;-)

First, I committed the files from your email.

Then I fixed the doctests for both configobj.py and validate.py to make
them work on Python 2.2.3 . I even tried Python 2.1.3, but it would have
taken too many changes, so I dropped it. Only one test, for validate.py,
still fails on 2.2.3, for trivial reasons.

Finally I converted a rather elaborate config file from ZConfig format to
Configobj. All is well as far as values go, but I have two non-trivial
problems with validation.

The first one: there is no default value. There should be a way to check a
param's value, when it is set in the config file, or else to fill in a
default value when it is not. As it is, one may leave the configspec empty,
meaning that the value may not be present: alas, by doing so one loses any
check on the value, and there's no default value anyway.

This default value business is very handy, because it allows to specify, in
the config file, just the values that differ from the defaults.

The second problem is deeper: the configspec is monolitic, and I need it to
be modular. That is, some sections contain a number of homogeneous
subsections, and there's no way to know beforehand how many they will be.
They should reuse the same configspec, so should be somehow declared of a
certain "type", and validation should have a way to pick the right
configspec fragment.

This may be related to what you wrote:

> Hmmm... Well I want to get validate working as a Section attribute rather
> than an attribute just on ConfigObj...

ZConfig does this by reusing section types in "multisections". Probably we
could do something similar by validating the configspec for Sections, and
then composing them in the complete configspec for the ConfigObj.

By the way, maybe you could give a look to the ZConfig doc PDF, if you
didn't already. There may be some good ideas in there, amidst all the
formality ;-) :

http://svn.zope.org/*checkout*/ZConfig/trunk/doc/zconfig.pdf?rev=30398

If we can solve these two problems, I think we can set the Configobj status
straight to "beta", from my POV at least. ;-)

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

Abstraction is layering ignorance on top of reality.
 -- rpg, cited by Richard P. Gabriel, November 2002