rest2web-develop

[Rest2web-develop] "none" and "multiple" checks are no more :-)

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

configobj.py
------------

Actually added the RepeatSectionError class. ;-)

validate.py
-----------

Deleted the "none" and "multiple" checks, and good riddance, I'd say. ;-)

Added the None value in Validation.check: now None is an admissible value
for all checks. When specified in the defaults, it affords an easy way to
omit a key from the config without having a real default, making it
effectively optional.


It currently happens that if a section has only scalars with defaults, and
__many__ subsections, it may be omitted from the config, making it optional
too. I like it that way. :-)

I also updated the validate.txt doc, deleting mentions of the "none" and
"multiple" checks, and adding a mention of None as an admissible value for
all checks.

I've been able to complete my use case. I now have a good configspec, and
both a complete and (very) minimal config that comply with the configspec.
I'm satisfied with the results, and have no further feature requests. ;-D

The real test will happen when I integrate it in the code, but that will
have to wait some time. I don't expect problems, apart from the fact that
currently config is traversed with dot (attribute) notation, and all uses
will have to be converted to dict notation.

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

Python is the best thing I've seen in 30 years of computing for
pedogogical and productive purposes. Only when I want speed do I
see a need for something else. -- Chuck Allison, June 2005

Re: [Rest2web-develop] "none" and "multiple" checks are no more :-)

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

Nicola Larosa wrote:
> configobj.py
> ------------
> 
> Actually added the RepeatSectionError class. ;-)
> 

Oops *blush*.

There's also another change I claimed to have made that I should
actually do :-)

> validate.py
> -----------
> 
> Deleted the "none" and "multiple" checks, and good riddance, I'd say. ;-)
> 
> Added the None value in Validation.check: now None is an admissible value
> for all checks. When specified in the defaults, it affords an easy way to
> omit a key from the config without having a real default, making it
> effectively optional.
> 

Cool. Nice one.

I did some more work on the docs, but still not finished. I need to look
over the 'final' implementation - particularly for validate.

As always your proofreading will be appreciated. Same applies to module
docstrings.

I'm going to prepare a release based on this...


> 
> It currently happens that if a section has only scalars with defaults, and
> __many__ subsections, it may be omitted from the config, making it optional
> too. I like it that way. :-)
> 
> I also updated the validate.txt doc, deleting mentions of the "none" and
> "multiple" checks, and adding a mention of None as an admissible value for
> all checks.
> 
> I've been able to complete my use case. I now have a good configspec, and
> both a complete and (very) minimal config that comply with the configspec.
> I'm satisfied with the results, and have no further feature requests. ;-D
> 
> The real test will happen when I integrate it in the code, but that will
> have to wait some time. I don't expect problems, apart from the fact that
> currently config is traversed with dot (attribute) notation, and all uses
> will have to be converted to dict notation.
> 

Ok - adding attribute access would be easy (ConfigObj3 has it). I'd
rather not have it as a feature (I think dictionary notation is more
appropriate; members are members, not attributes) - but writing a
wrapper class would be simple..... (Better to switch to the new way
though..)


All the best,


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

Re: [Rest2web-develop] "none" and "multiple" checks are no more :-)

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

> I did some more work on the docs, but still not finished. I need to look
> over the 'final' implementation - particularly for validate.
> 
> As always your proofreading will be appreciated. Same applies to module
> docstrings.
> 
> I'm going to prepare a release based on this...

Let me know once you have updated the docs, and before release. Are you
going to release just ConfigObj, or the whole PythonUtils? The CaselessDict
is still there... ;-)


>> The real test will happen when I integrate it in the code, but that will
>> have to wait some time. I don't expect problems, apart from the fact that
>> currently config is traversed with dot (attribute) notation, and all uses
>> will have to be converted to dict notation.

> Ok - adding attribute access would be easy (ConfigObj3 has it). I'd
> rather not have it as a feature (I think dictionary notation is more
> appropriate; members are members, not attributes) - but writing a
> wrapper class would be simple..... (Better to switch to the new way
> though..)

I'm torn on this issue.

On one hand I'd like to avoid all that rewriting, and I like attribute
access better, from both a writing and reading point of view. I don't think
appropriateness is really an issue, BTW: it's just semantic quibbling. :-)

On the other I don't like the fact that it's less general than member
notation: one can only use legal Python identifiers for attribute access.
This isn't usually a practical problem, and can be worked around with
getattr: then it would get so ugly that in that case member notation is
preferable. :-)

In the end, balancing pros and cons, I'd say that it would be worthwhile to
restore it, if you can find a clean, little-disruptive way. How would that
wrapper class work?

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

Python is the best thing I've seen in 30 years of computing for
pedogogical and productive purposes. Only when I want speed do I
see a need for something else. -- Chuck Allison, June 2005

Re: [Rest2web-develop] "none" and "multiple" checks are no more :-)

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

Nicola Larosa wrote:
>>I did some more work on the docs, but still not finished. I need to look
>>over the 'final' implementation - particularly for validate.
>>
>>As always your proofreading will be appreciated. Same applies to module
>>docstrings.
>>
>>I'm going to prepare a release based on this...
> 
> 
> Let me know once you have updated the docs, and before release. Are you
> going to release just ConfigObj, or the whole PythonUtils? The CaselessDict
> is still there... ;-)
> 

Yeah - I haven't removed it yet, I have *slight* issues as I do my
editing in three different places which makes editing the repository
structure *difficult*. (svn files require administrator access to change
- which means my directory sync utility sometimes fails to properly
synchronise changes to the repository admin files - this means
structural changes sometimes corrupt my working copy).

I *will* do a new pythonutils release - featuring odict and removing
caseless. I'd *rather* do a full review of the other modules in it
(rather than have future instability), but I don't know if I have time.
I'd like to keep listquote as I know several people are using it - but
lineparse needs re-writing which is actually quite a big job.

> 
> 
>>>The real test will happen when I integrate it in the code, but that will
>>>have to wait some time. I don't expect problems, apart from the fact that
>>>currently config is traversed with dot (attribute) notation, and all uses
>>>will have to be converted to dict notation.
> 
> 
>>Ok - adding attribute access would be easy (ConfigObj3 has it). I'd
>>rather not have it as a feature (I think dictionary notation is more
>>appropriate; members are members, not attributes) - but writing a
>>wrapper class would be simple..... (Better to switch to the new way
>>though..)
> 
> 
> I'm torn on this issue.
> 
> On one hand I'd like to avoid all that rewriting, and I like attribute
> access better, from both a writing and reading point of view. I don't think
> appropriateness is really an issue, BTW: it's just semantic quibbling. :-)
> 

Hmm... I disagree, I think confusing object attributes with members of
the config file is a mistake. Ha - normally you're the one arguing for a
purer and less confusing semantics.

> On the other I don't like the fact that it's less general than member
> notation: one can only use legal Python identifiers for attribute access.
> This isn't usually a practical problem, and can be worked around with
> getattr: then it would get so ugly that in that case member notation is
> preferable. :-)
> 
> In the end, balancing pros and cons, I'd say that it would be worthwhile to
> restore it, if you can find a clean, little-disruptive way. How would that
> wrapper class work?
> 

Damn... I don't think a straight subclass will do, it would have to be a
change to Section (since you are doing attribute access on sections as
well...).

This change to Section implements it (untested) :

Add this line to the bottom of Section.__init__

        self._initialised = True

Then add :

    def __getattr__(self, item):
        """Maps values to attributes."""
        try:
            return self.__getitem__(item)
        except KeyError:
            raise AttributeError(item)

    def __setattr__(self, item, value):
        """Maps attributes to values."""
        if not self.__dict__.has_key('_initialised'):
            # allows you to set normal attributes in __init__
            dict.__setattr__(self, item, value)
        elif self.__dict__.has_key(item):
            dict.__setattr__(self, item, value)
        else:
            self.__setitem__(item, value)

    def __delattr__(self, item):
        """Maps attribute deletion to members."""
        # MIKE: should we prevent attribute deletion here ?
        if self.__dict__.has_key(item):
            dict.__delattr__(self, item)
        else:
            dict.__delitem__(self, item)


By the way - preventing OrderedDict from being initialised from a
dictionary makes it much harder to use it as a baseclass for Section :-)

I have no IRC today :-(

Regards,

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