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