rest2web-develop — A discussion list for rest2web development.

Re: [Rest2web-develop] None and Defaults

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

Hello Nicola,

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 16/08/05 20:05:46
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] None and Defaults
     >> What about attribute access - we leaving it in ?
   >
   >I'd like to keep it, yes, but...
   >
   >
   >> Lots of Section attributes clash with possible key names - 'defaults',
   >> 'sections', 'scalars', etc
   >
   >...this is unacceptable. At the very least they could be renamed with
   >double underscore before and after, or even better they should be separated
   >in an appropriate namespace somehow. That's also true of ConfigObj parameters.
   >

This is exactly why attribute access is bad.

The object namespace is the RIGHT place. These *are* public attributes of the section. Are you going to move section methods to another namespace as well ? (a rhetorical question).

All the private attributes/methods already start with a single underscore.

   >Let's decide on an approach and I'll do the dirty work, promised. :-)
   >

I'm -1 on moving/removing Section/ConfigObj attributes.

I don't *mind* leaving attribute access in - but I don't like it especially.

Best Regards, 


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


   >-- 
   >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
   >
   >
   >
   >-------------------------------------------------------
   >SF.Net email is Sponsored by the Better Software Conference & EXPO
   >
   >   >

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

Re: [Rest2web-develop] None and Defaults

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

> What about attribute access - we leaving it in ?

I'd like to keep it, yes, but...


> Lots of Section attributes clash with possible key names - 'defaults',
> 'sections', 'scalars', etc

...this is unacceptable. At the very least they could be renamed with
double underscore before and after, or even better they should be separated
in an appropriate namespace somehow. That's also true of ConfigObj parameters.

Let's decide on an approach and I'll do the dirty work, promised. :-)

-- 
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 Defaults

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

Ok.

What about attribute access - we leaving it in ?

Lots of Section attributes clash with possible key names - 'defaults', 'sections', 'scalars', etc

Fuzz

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 16/08/05 17:09:41
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] None and Defaults
   >
   >>> I'm cool with the "None" string, by itself, always meaning the None value,
   >>> like True or False, but not restricted to one check type. Maybe we should
   >>> take out that "lower" method, though.
   >
   >> I'm not - ConfigObj shouldn't change the type without the programmer
   >> specifying it.
   >
   >Good point.
   >
   >
   >> Don't forget the value is set by the *user* - not the programmer.
   >> ConfigObj should only convert type if the programmer says. None
   >> shouldn't be an acceptable value for every check - maybe it *isn't* an
   >> acceptable value (what if the programmer really does want an integer
   >> there - he expects validate to tell him).
   >
   >Yes, actually None is a value of type NoneType. Hadn't realized that
   >before, was thinking of it as an amorphous no-type-every-type non-value.
   >
   >
   >> This means that someone's program will break because a user enters
   >> 'None' as a string value. It ought to be possible to have 'None' as a
   >> string value in a config file without our program converting it to
   >> another type.
   >
   >Another good point.
   >
   >
   >> I thought the point was to catch defaults ?
   >
   >Yes, it was, but then I incautiously adventured into YAGNI land. ;-)
   >
   >
   >> My proposed (and currently committed) solution allows the programmer to
   >> specify that None is ok (by using default='None'), which makes the value
   >> explicitly (user sets value as 'None')
   >
   >I don't think the user may explicitly set a None value, now, but it may as
   >well be that way.
   >
   >
   >> and implicitly (user omits value altogether) optional.
   >
   >That's probably enough.
   >
   >
   >> I'm fine with removing the 'lower'.
   >
   >So be it. Sorry for the confusion.
   >
   >-- 
   >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
   >
   >
   >
   >-------------------------------------------------------
   >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] None and Defaults

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

>> I'm cool with the "None" string, by itself, always meaning the None value,
>> like True or False, but not restricted to one check type. Maybe we should
>> take out that "lower" method, though.

> I'm not - ConfigObj shouldn't change the type without the programmer
> specifying it.

Good point.


> Don't forget the value is set by the *user* - not the programmer.
> ConfigObj should only convert type if the programmer says. None
> shouldn't be an acceptable value for every check - maybe it *isn't* an
> acceptable value (what if the programmer really does want an integer
> there - he expects validate to tell him).

Yes, actually None is a value of type NoneType. Hadn't realized that
before, was thinking of it as an amorphous no-type-every-type non-value.


> This means that someone's program will break because a user enters
> 'None' as a string value. It ought to be possible to have 'None' as a
> string value in a config file without our program converting it to
> another type.

Another good point.


> I thought the point was to catch defaults ?

Yes, it was, but then I incautiously adventured into YAGNI land. ;-)


> My proposed (and currently committed) solution allows the programmer to
> specify that None is ok (by using default='None'), which makes the value
> explicitly (user sets value as 'None')

I don't think the user may explicitly set a None value, now, but it may as
well be that way.


> and implicitly (user omits value altogether) optional.

That's probably enough.


> I'm fine with removing the 'lower'.

So be it. Sorry for the confusion.

-- 
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 Defaults

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

Nicola Larosa wrote:
>>I have a question about your changes to validate regarding None :
>>
>>Specifically this code :
>>        if missing:
>>            try:
>>                value = fun_kwargs['default']
>>            except KeyError:
>>                raise ValidateMissingValue
>>        # None is an admissible value for all types
>>        if isinstance(value, StringTypes) and (value.lower() == 'none'):
>>            return None
>>
>>This means that the string 'none' in a value will *always* be converted
>>to ``None``. I think this should only happen if 'none' is the default
>>value and the value itself is missing.
> 
> 
> Maybe somebody would like to explicitly put a None value in the config
> value, instead of just omitting it and having to say "default = None" in
> the configspec. Maybe the default is something else, and there's a need to
> unset a value in the config.
> 
> I'm cool with the "None" string, by itself, always meaning the None value,
> like True or False, but not restricted to one check type. Maybe we should
> take out that "lower" method, though.
> 

I'm not - ConfigObj shouldn't change the type without the programmer
specifying it.

Don't forget the value is set by the *user* - not the programmer.
ConfigObj should only convert type if the programmer says. None
shouldn't be an acceptable value for every check - maybe it *isn't* an
acceptable value (what if the programmer really does want an integer
there - he expects validate to tell him).

> 
> 
>>Also - in case validate is called later ``None`` ought to always go
>>through (e.g. to verify user changes to the config file made via a GUI).
> 
> 
> That's right, I didn't think about that, good catch.
> 
> 
> 
>>These two changes make the code (I think) :
>>
>>        if missing:
>>            try:
>>                value = fun_kwargs['default']
>>            except KeyError:
>>                raise ValidateMissingValue
>>            # None is an admissible value for all types
>>            if isinstance(value, StringTypes) and (value.lower() == 'none'):
>>                value = None
>>        if value is None:
>>            return None
> 
> 
> Then it would become something like:
> 
>          if missing:
>              try:
>                  value = fun_kwargs['default']
>              except KeyError:
>                  raise ValidateMissingValue
>          # None is an admissible value for all types
>          if (value is None) or (value == 'None'):
>              return None
> 

This means that someone's program will break because a user enters
'None' as a string value. It ought to be possible to have 'None' as a
string value in a config file without our program converting it to
another type.

I thought the point was to catch defaults ?

My proposed (and currently committed) solution allows the programmer to
specify that None is ok (by using default='None'), which makes the value
explicitly (user sets value as 'None') and implicitly (user omits value
altogether) optional. I'm fine with removing the 'lower'.

All the best,

Fuzzy

Re: [Rest2web-develop] None and Defaults

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

> Commit done anyway - minor changes to ConfigObj and validate.

You can still do another one, if needed. ;-)

-- 
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 Defaults

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

> I have a question about your changes to validate regarding None :
> 
> Specifically this code :
>         if missing:
>             try:
>                 value = fun_kwargs['default']
>             except KeyError:
>                 raise ValidateMissingValue
>         # None is an admissible value for all types
>         if isinstance(value, StringTypes) and (value.lower() == 'none'):
>             return None
> 
> This means that the string 'none' in a value will *always* be converted
> to ``None``. I think this should only happen if 'none' is the default
> value and the value itself is missing.

Maybe somebody would like to explicitly put a None value in the config
value, instead of just omitting it and having to say "default = None" in
the configspec. Maybe the default is something else, and there's a need to
unset a value in the config.

I'm cool with the "None" string, by itself, always meaning the None value,
like True or False, but not restricted to one check type. Maybe we should
take out that "lower" method, though.


> Also - in case validate is called later ``None`` ought to always go
> through (e.g. to verify user changes to the config file made via a GUI).

That's right, I didn't think about that, good catch.


> These two changes make the code (I think) :
> 
>         if missing:
>             try:
>                 value = fun_kwargs['default']
>             except KeyError:
>                 raise ValidateMissingValue
>             # None is an admissible value for all types
>             if isinstance(value, StringTypes) and (value.lower() == 'none'):
>                 value = None
>         if value is None:
>             return None

Then it would become something like:

         if missing:
             try:
                 value = fun_kwargs['default']
             except KeyError:
                 raise ValidateMissingValue
         # None is an admissible value for all types
         if (value is None) or (value == 'None'):
             return None

-- 
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 Defaults

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

Commit done anyway - minor changes to ConfigObj and validate.

Michael Foord wrote:
> Hello Nicola,
> 
> About to commit a few minor changes to ConfigObj.
> 
> I have a question about your changes to validate regarding None :
> 
> Specifically this code :
>         if missing:
>             try:
>                 value = fun_kwargs['default']
>             except KeyError:
>                 raise ValidateMissingValue
>         # None is an admissible value for all types
>         if isinstance(value, StringTypes) and (value.lower() == 'none'):
>             return None
> 
> This means that the string 'none' in a value will *always* be converted
> to ``None``. I think this should only happen if 'none' is the default
> value and the value itself is missing.
> 
> Also - in case validate is called later ``None`` ought to always go
> through (e.g. to verify user changes to the config file made via a GUI).
> 
> These two changes make the code (I think) :
> 
>         if missing:
>             try:
>                 value = fun_kwargs['default']
>             except KeyError:
>                 raise ValidateMissingValue
>             # None is an admissible value for all types
>             if isinstance(value, StringTypes) and (value.lower() == 'none'):
>                 value = None
>         if value is None:
>             return None
> 
> Fuzzy
> 
> 
> -------------------------------------------------------
> 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
> 
> 
> 

[Rest2web-develop] None and Defaults

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

Hello Nicola,

About to commit a few minor changes to ConfigObj.

I have a question about your changes to validate regarding None :

Specifically this code :
        if missing:
            try:
                value = fun_kwargs['default']
            except KeyError:
                raise ValidateMissingValue
        # None is an admissible value for all types
        if isinstance(value, StringTypes) and (value.lower() == 'none'):
            return None

This means that the string 'none' in a value will *always* be converted
to ``None``. I think this should only happen if 'none' is the default
value and the value itself is missing.

Also - in case validate is called later ``None`` ought to always go
through (e.g. to verify user changes to the config file made via a GUI).

These two changes make the code (I think) :

        if missing:
            try:
                value = fun_kwargs['default']
            except KeyError:
                raise ValidateMissingValue
            # None is an admissible value for all types
            if isinstance(value, StringTypes) and (value.lower() == 'none'):
                value = None
        if value is None:
            return None

Fuzzy

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

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:
> 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

[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] DateUtil and None (ConfigObj)

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

Hello Nicola,

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 15/08/05 19:44:08
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] DateUtil and None (ConfigObj)
     >> I *could* implement a timestamp datatype using the ``parse`` function
   >> from the third party DateUtil module.
   >> 
   >> http://moin.conectiva.com.br/DateUtil#head-95324de690ad48fe8f91bdee9b5bf97b6b0911e9
   >
   >Don't know what it does beyond the datetime standard one, maybe the time
   >zones? Anyway, I'll look at it.
   >
   >

The *relevant* bit is the parse function - which has no equivalent in datetime...

Best Regards, 


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

Re: [Rest2web-develop] DateUtil and None (ConfigObj)

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

> I *could* implement a timestamp datatype using the ``parse`` function
> from the third party DateUtil module.
> 
> http://moin.conectiva.com.br/DateUtil#head-95324de690ad48fe8f91bdee9b5bf97b6b0911e9

Don't know what it does beyond the datetime standard one, maybe the time
zones? Anyway, I'll look at it.


> I *don't* actually need it - like you I record timestamps. What do you
> think - YAGNI ? (or a useful reference implementation with a conditional
> import.....)

It would sure be nice, but I've had my share of headaches with timestamps...


> Are you intending to remove the None test ?

Yes. :-) I'm going to move the relevant two lines to Validator.check, and
delete the rest.


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

Does it seem like I'm looking for an answer
To a question I can't ask
 -- Norah Jones, Nightingale, Come Away with Me, 2001

[Rest2web-develop] DateUtil and None (ConfigObj)

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

A couple of questions :

I *could* implement a timestamp datatype using the ``parse`` function
from the third party DateUtil module.

http://moin.conectiva.com.br/DateUtil#head-95324de690ad48fe8f91bdee9b5bf97b6b0911e9

I *don't* actually need it - like you I record timestamps. What do you
think - YAGNI ? (or a useful reference implementation with a conditional
import.....)

Are you intending to remove the None test ?

All the best,


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

Re: [Rest2web-develop] Misc fixes, and a last request

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

Just got your other email - at work now. I haven't yet committed my
changes... will do any minute.....

Meet you on IRC ??

Nicola Larosa wrote:
> Almost completed the translation of my main use case from ZConfig to
> ConfigObj. Changed a few things:
> 
> configobj.py
> ------------
> 
> Reworked the ConfigObj._parse, _handle_error and _multiline methods:
> mutated the self._infile, self._index and self._maxline attributes into
> local variables and method parameters.
> 
> Reshaped the ConfigObj._multiline method to better reflect its semantics.
> 
> Changed the "default_test" test in ConfigObj.validate to check the fix for
> the bug in validate.Validator.check (see below).
> 
> Added a test to SimpleVal: it does not seem able to intercept missing
> values, please check it.
> 
> Commented out the following line in SimpleVal:
> 
>   baseErrorClass = Exception
> 
> it's what causes the exception in doctest in Python2.2, and doesn't seem
> needed anyway: if it is, write a test that uses it. :-)
> 

I've sorted SimpleVal - it stopped working when we added default values.

It now works - and *needs* self.baseErrorClass, which it has to raise
when a value is missing. I've set ``baseErrorClass`` to
``ConfigObjError`` - and made it an instance attribute rather than a
class attribute. Hopefully this will remove the doctest problem (?).

> validate.py
> -----------
> 
> Fixed a bug in Validator.check: when a value that has a default is also
> specified in the config file, the default must be deleted from fun_kwargs
> anyway, otherwise the check function will get a spurious "default" keyword
> argument.
> 
> Added an "ip_addr_list" check.
> 

Cool - I've removed all references to timestamp, other than a mention in
the TODO list.

> odict.py
> --------
> 
> Cosmetic changes only, to get PyLint to give it a "10" score. It's the
> first time I manage to do that. :-)
> 
> Maximum score from PyLint and extensive test coverage, that's probably the
> best Python Ordered Dictionary in the known universe. ;-D
> 

Fantastic. :-)

> The last request
> ----------------
> 
> Really the last, I promise. O:-)
> 
> It's about required values, and required sections.
> [snip..]

Awaiting your response to my suggestions (including the suggestion that
you code the chosen implementation). We need to make a decision as the
only bits of documentation that still need work is (still) the
validation related stuff.

All the best,


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

Re: [Rest2web-develop] Misc fixes, and a last request

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

> My friend has said he will setup the unixshell account for us - but no
> details yet.

Great.


> This is exactly the *opposite* of the way configspecs currently work. If
> no default is specified the value must be specified.
>
> My normal use case is that defaults are not specified and values are not
> optional.
>
> I don't like the 'default is keys are optional' solution - it seems to me
> to reverse the primary rationale of configspecs. Also - it makes writing
> quick and simple configspecs more painful.

I agree. I was just trying to avoid adding another keyword, but didn't like
the inversion of policy either, so keys stay mandatory.

Thinking about it, the specification "default = None" should mean exactly
what it says, that is, if no value is specified in the config, the key gets
the value "None".


> *Also* - None is a possible value to pass to default.

This is the key of the solution to the problem.

Currently, "None" is only usable if a key is of type "none". But such a
type is useless: what can you do with an option that can only assume the
"None" (non-)value? :-) The only use case I currently see is as a value in
"multiple" types.

Thinking more about it, I'd say instead that the "None" type should be a
legal value for all types, with the same meaning as NULL in SQL, that is,
no real value specified. Same meaning as in Python, incidentally. ;-)

Then you can add "default = None" to *any* type, meaning that if no value
is  present in the config, that key gets the "None" (non-)value, that is,
no real value.

This also solves a remaining problem: specifying a default value for list
types, currently not possible.

Obviously, now that "None" is always a legal (non-)value, the "none" type
is not needed anymore, and goes away. :-)


> Possible alternatives :

[mumbo-jumbo deleted ;-) ]

We can forget about all that. :-)


>> A similar issue is the requiredness of sections: I need to be able to
>> omit entire sections from the config, and this is currently not
>> possible.

> An __optional__ scalar value in the configspec ? (true or false)
>
> You could even combine with __optional_scalars__ - and just make
> __optional__ a list that can include sections and scalars. Then only one
> more magic value is needed.

I decided to do away with that, and require that all sections must always
be present, even if empty. It's not worth the added complication.


>> A related issue would be specifying the min and max number of
>> subsections in __many__ sections.

> __min__ and __max__ magic scalars in __many__ sections ?

Archived under YAGNI.


I'm working on this now, today's holiday in Italy, but not in England
apparently, so if you are at work let me know about it as soon as you can.


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

Does it seem like I'm looking for an answer
To a question I can't ask
 -- Norah Jones, Nightingale, Come Away with Me, 2001

RE: [Rest2web-develop] Misc fixes, and a last request

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

Hello Nicola,

My friend has said he will setup the unixshell account for us - but no details yet.

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 14/08/05 19:42:22
[snip..]

All your work/fixes sound very good.

   >The last request
   >----------------
   >
   >Really the last, I promise. O:-)
   >
   >It's about required values, and required sections.
   >
   >Currently, if a scalar has no default in the configspec, it must be
   >specified in the config, therefore in the end every scalar has a value. But
   >I need optional values, with no default, and possibly not specified in the
   >config, so that they may effectively be missing from the config obj.
   >
   >We could decide that when a scalar is defined with "default = None", then
   >it means that it's required, otherwise it may be altogether absent from the
   >config. In that case, the default would be for all values not to be
   >required: the opposite would have to be explicitly specified.
   >

This is exactly the *opposite* of the way configspecs currently work. If no default is specified the value must be specified.

My normal use case is that defaults are not specified and values are not optional.

*Also* - None is a possible value to pass to default. 

Possible alternatives :

1) How about a new ``optional`` keyword ? I would have it default to False - but you could override this with a new option ?

2) We could create a new value for ``default`` - say ``Force`` - meaning the value is optional ?

3) You could always do it yourself programatically of course - use  '__OPTIONAL__'  as your default value and then delete all members that have this value..... It may need a slight alteration to 'walk' (you couldn't delete members of a section whilst iterating over it - have to iterate over a copy of the keys).

4) Hmmm... What about an ``__optional_scalars__`` list of keys for a section ?


I don't like the 'default is keys are optional' solution - it seems to me to reverse the primary rationale of configspecs. Also - it makes writing quick and simple configspecs more painful.

Adding an extra keyword is clumsy - but making it impossible to have None as a default value doesn't seem good either. I favour options 3 or 4.
  
   >A similar issue is the requiredness of sections: I need to be able to omit
   >entire sections from the config, and this is currently not possible.

An __optional__ scalar value in the configspec ? (true or false)

You could even combine with __optional_scalars__ - and just make __optional__ a list thatan include sections and scalars. Then only one more magic value is needed.  

   >A related issue would be specifying the min and max number of subsections in
   >__many__ sections.
   >

__min__ and __max__ magic scalars in __many__ sections ?

   >All the rest works, the requiredness issue should be all that's missing for
   >my use case. What about it? :-)
   >

LOL
Hmmm.... Who's gonna implement all this ? You're pretty familiar with the code now Nicola ;-p

Best Regards, 

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

   >-- 
   >Nicola Larosa - ni...@te...
   >
   >Does it seem like I'm looking for an answer
   >To a question I can't ask
   > -- Norah Jones, Nightingale, Come Away with Me, 2001
   >
   >
   >
   >
   >-------------------------------------------------------
   >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
   >
   >
   >

[Rest2web-develop] Misc fixes, and a last request

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

Almost completed the translation of my main use case from ZConfig to
ConfigObj. Changed a few things:

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

Reworked the ConfigObj._parse, _handle_error and _multiline methods:
mutated the self._infile, self._index and self._maxline attributes into
local variables and method parameters.

Reshaped the ConfigObj._multiline method to better reflect its semantics.

Changed the "default_test" test in ConfigObj.validate to check the fix for
the bug in validate.Validator.check (see below).

Added a test to SimpleVal: it does not seem able to intercept missing
values, please check it.

Commented out the following line in SimpleVal:

  baseErrorClass = Exception

it's what causes the exception in doctest in Python2.2, and doesn't seem
needed anyway: if it is, write a test that uses it. :-)

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

Fixed a bug in Validator.check: when a value that has a default is also
specified in the config file, the default must be deleted from fun_kwargs
anyway, otherwise the check function will get a spurious "default" keyword
argument.

Added an "ip_addr_list" check.

odict.py
--------

Cosmetic changes only, to get PyLint to give it a "10" score. It's the
first time I manage to do that. :-)

Maximum score from PyLint and extensive test coverage, that's probably the
best Python Ordered Dictionary in the known universe. ;-D

The last request
----------------

Really the last, I promise. O:-)

It's about required values, and required sections.

Currently, if a scalar has no default in the configspec, it must be
specified in the config, therefore in the end every scalar has a value. But
I need optional values, with no default, and possibly not specified in the
config, so that they may effectively be missing from the config obj.

We could decide that when a scalar is defined with "default = None", then
it means that it's required, otherwise it may be altogether absent from the
config. In that case, the default would be for all values not to be
required: the opposite would have to be explicitly specified.

A similar issue is the requiredness of sections: I need to be able to omit
entire sections from the config, and this is currently not possible. A
related issue would be specifying the min and max number of subsections in
__many__ sections.

All the rest works, the requiredness issue should be all that's missing for
my use case. What about it? :-)

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

Does it seem like I'm looking for an answer
To a question I can't ask
 -- Norah Jones, Nightingale, Come Away with Me, 2001

[Rest2web-develop] odict doctests and fixes done

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

I've completed the doctests for odict.py, and reworked the whole file.

It's unbelievable how long it takes to fix all the corner cases, and how
much tests help. :-) I simplified and fixed most of the code.

I also restricted a couple of things.

Now an OrderedDict can only be init'ed from a sequence of 2-item sequences,
like a plain dict:

d = OrderedDict((
    (1, 1),
    (2, 2),
    (3, 3),
))

or else it can be created empty, and the have items set aftewards:

d = OrderedDict()
d[1] = 1
d[2] = 2
d[3] = 3

Neither a plain dict nor keyword args can be passed in anymore, because
there's no way to determine the order of items, with them.

The same holds for updates and comparisons: they're only meaningful between
OrderedDicts.

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

Does it seem like I'm looking for an answer
To a question I can't ask
 -- Norah Jones, Nightingale, Come Away with Me, 2001

Re: [Rest2web-develop] Repeated Section

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

Michael Foord wrote:
> Hello All,
> 
> I've just committed changes to ConfigObj that implement repeated
> sections using the '__many__' section name in the configspec.
> 
> The actual code is about twenty lines - plus nearly 70 lines of tests.
> 
> If a section of a configspec (including the root section) has a
> sub-section called '__many__' - then *this* is the configspec that will
> be applied to *all* sub-sections in that section. 

The implied restriction here is that if you supply any other specs in
your configspec they will be ignored - and just the '__many__' one used.

This could be changed; either to raise an error - or to 'update' the
dictionary (was update around as a method of dictionaries in python 2.2
?) rather than replace it (so that the '__many__' and any additional
checks could be used).

I've done another minor commit to correct a couple of whitespace errors
in a docstring.

I'm now (again/still) working on getting the documentation up to date.

Regards,

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


> The '__many__'
> sub-section can itself have nested sections, including nested '__many__'
> sections.
> 
> E.g.
> 
> [cats]
> 
>    [[__many__]]
>     age = float(0, default=5)
>     height = float(default=0.25)
>     mood = option(grumpy, aloof, vain, default=aloof)
>    [[[description]]]
>        coat = option(brown, grey, black, "tortoise shell", default=brown)
>    [[[fleas]]]
>        [[[[__many__]]]]
>        bloodsucker = boolean(default=True)
>        children = integer(0, default=1000)
> 
> The above configspec creates a section called 'cats'. Any subsection in
> 'cats' must match the '__many__' configspec. So each cat has several
> attributes (including a subsection called 'description'). Each cat can
> also optionally have many fleas....
> 
> Because all the checks have defaults - if you create any empty cats and
> then call validate, the default values will be filled in.
> 
> Nicola - you will need to properly format the doctests - as well as
> check that I haven't broken anything and that it works as advertised.
> 
> (By the way floats become numbers like 3.000000001 when converted
> backwards and forward. Decimal would be better - but is a Python 2.4
> module. This might not matter.)
> 
> 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
> 
> 
> 

[Rest2web-develop] Repeated Section

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

Hello All,

I've just committed changes to ConfigObj that implement repeated
sections using the '__many__' section name in the configspec.

The actual code is about twenty lines - plus nearly 70 lines of tests.

If a section of a configspec (including the root section) has a
sub-section called '__many__' - then *this* is the configspec that will
be applied to *all* sub-sections in that section. The '__many__'
sub-section can itself have nested sections, including nested '__many__'
sections.

E.g.

[cats]

   [[__many__]]
    age = float(0, default=5)
    height = float(default=0.25)
    mood = option(grumpy, aloof, vain, default=aloof)
   [[[description]]]
       coat = option(brown, grey, black, "tortoise shell", default=brown)
   [[[fleas]]]
       [[[[__many__]]]]
       bloodsucker = boolean(default=True)
       children = integer(0, default=1000)

The above configspec creates a section called 'cats'. Any subsection in
'cats' must match the '__many__' configspec. So each cat has several
attributes (including a subsection called 'description'). Each cat can
also optionally have many fleas....

Because all the checks have defaults - if you create any empty cats and
then call validate, the default values will be filled in.

Nicola - you will need to properly format the doctests - as well as
check that I haven't broken anything and that it works as advertised.

(By the way floats become numbers like 3.000000001 when converted
backwards and forward. Decimal would be better - but is a Python 2.4
module. This might not matter.)

Best Regards,


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

Re: [Rest2web-develop] Repeated Sections

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

> So unless you've already done it Nicola - I'll do it. :-D

Of course, go ahead: who am I to try stopping progress? ;-D

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

Does it seem like I'm looking for an answer
To a question I can't ask
 -- Norah Jones, Nightingale, Come Away with Me, 2001

[Rest2web-develop] Repeated Sections

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

Hello Nicola,

Ok, so I cycled home, meditated, had a shower - and the answer popped out :-)

I think I can implement repeated sections in very little code :-) Basically the validate method should dynamically assign the configspec attribute to subsections. If this configspec has the whole tree in it then this will automatically be propagated to subsections as validate moves down the tree.... It needs a slight modification to parsing configspecs.

So unless you've already done it Nicola - I'll do it. :-D

Best Regards,


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