rest2web-develop — A discussion list for rest2web development.

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

> 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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

> 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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

> 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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

> 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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

> 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

Re: [Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

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

[Rest2web-develop] Changed all references to value "tests" into value "checks"...

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

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

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

> I didn't *like* the initial implemntation. I thought you could achieve
> the identical thing with a single function (method ?) and a dictionary.
> 
> Also the example ones looked horribly complicated and not *that* useful.
> I'd prefer it if the examples we supply are at least comprehensible.
> 
> It's possible I was wrong and it's just because it was code I didn't
> write :-)
> 
> I'd be quite happy for you to implement something - or I'll put
> something back when I've done ConfigObj.

We'll see.


>> You want Quixote's PTLs, man. You *really* want them. :-) What are they?
>> Text generation through real Python, that's what. BTW, I share your dislike
>> of embedded mini-languages for templating.

> I don't yet know you well enough to know when you're being facetious.
> Are you serious that I would like PTL ?

Too many smiling faces, probably. Yes, I'm serious. Two years ago there was
no Nevow in Twisted, only Woven, its precursor (and from where it took its
name :-) ). I tried using it, but couldn't grasp its form processing, so I
turned back to old faithful Quixote, extracted the PTLs and the form
processing, and transplanted them into Twisted. And that's what we use
every day at my job, these days. :-)

Quixote's PTLs and Nevow's XHTML (with Zope's ZPT) are the two extremes of
the Python web templating spectrum, with almost nothing interesting in between.


> Which do you think would be more of a fruitful starting point ? -
> finding a twisted tutorial and ploughing in, or finding a twisted
> tutorial and trying to find my way in....

Looks like a Twisted tutorial would do you good. ;-D

It's true, too many choices in Python web templating. These days I'm hell
bent on Twisted, and leaning on Nevow, but Quixote is such a nice little
jewel that I think it's good having some familiarity with it.

Five-minutes crash course in Medusa+Quixote:

Download and install Medusa: http://www.amk.ca/python/code/medusa.html
do the same with Quixote: http://www.mems-exchange.org/software/quixote/
cd .../quixote/server
python medusa_http.py
Point your web browser to: http://localhost:8080/

That's it. :-) The Quixote docs are written with ReST, moreover. ;-)

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

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

Nicola Larosa wrote:
[snip..]
>>>I'd move the imports anyway, whether we separate the functions or not.
> 
> 
>>Cool - I'll leave you to do it next edit. I've done a couple of new
>>articles for my website (done my Romania blog and part II of my life
>>story as articles) - so I'm returning to editing ConfigObj.
> 
> 
> Let me know when you're able to let me play with it, too. :-)
> 
> 
> 

Hey - you can see the TODO list... let me know which bits you want to
take on ;-)

Seriously though - all the changes are pretty integrated and it makes
sense for me to do them all. Unfortunately implementing ``writein``
means refactoring the ``_parse`` method so I can use it. So until all
that lot is done.....

Shouldn't be *too* long though.

>>>For my use case, the IP address value is necessary, I wouldn't want to move
>>>it to some extra module. So let's keep everything local, at least until
>>>there's other stuff to be included that would make the module too unwieldy.
> 
> 
>>Ok - do you think it's worth implementing a generic 'regex' test (that
>>leaves values as strings), with a standard dict of (any ?) regexes.
> 
> 
> Maybe it would, but first I'd like to understand why you ripped'em off
> already. ;-)
> 

I didn't *like* the initial implemntation. I thought you could achieve
the identical thing with a single function (method ?) and a dictionary.

Also the example ones looked horribly complicated and not *that* useful.
I'd prefer it if the examples we supply are at least comprehensible.

It's possible I was wrong and it's just because it was code I didn't
write :-)

I'd be quite happy for you to implement something - or I'll put
something back when I've done ConfigObj.

> 
> 
>>Right.. hmm.. trying to fight my way through buzz words. I have a lot of
>>respect for Ian Bicking and the WSGI crew. I also like the idea of being
>>'back end independent'.
> 
> 
> Modularity is always a good idea, but it's hard, for anyone heavily bent on
> multithreading, to earn much respect with me, to put it bluntly.
> 

Hmmm.... I don't know enough to comment. But I couldn't resist putting
something....

> 
> 
>>I am also reasonably convinced that twisted is the way forward for any
>>decent web application - so if they're not compatible... then so be it.
> 
> 
> Of the two main strong points of Twisted, I think that the support of many
> net protocols is the *least* important one. The concurrency model makes it
> a strong base for *any* mid-to-big sized project, that is not enough served
> by multiprocessing.
> 
> 
> 
>>I'm interested in Nevow... *but* I like the ultra simplicity of
>>'embedded_code'. I don't yet understand what Nevow has to offer that is
>>more than templating. In fact most templating languages seem to me just
>>another new language (albeit simpler) to avoid embedding python - when
>>embedding python code is much more powerful (and I like Python).
> 
> 
> You want Quixote's PTLs, man. You *really* want them. :-) What are they?
> Text generation through real Python, that's what. BTW, I share your dislike
> of embedded mini-languages for templating.
> 

I don't yet know you well enough to know when you're being facetious.
Are you serious that I would like PTL ?

Which do you think would be more of a fruitful starting point ? -
finding a twisted tutorial and ploughing in, or finding a twisted
tutorial and trying to find my way in....

> Nevow is much more than templating. The other two main points are form
> processing and trasparent page update through Javascript (a superset of the
> currently popular Ajax).
> 

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

>> I take this as a "go ahead" with the "test" -> "check" renaming. :-)

> I thought I'd agreed. Anyway - no problem, we've completely broken
> backwards compatibility anyway (in lots of good ways - but anything
> using the new system is going to have to change code already).

Better safe than sorry, once bitten twice shy, and all that. ;-)


> I let Mark Andrews know that there was development work going on, but
> never heard back from him. He hasn't blogged for ages either - real life
> must be intruding, terrible stuff.

Or else a healthy, if late, disinterest in all these Internet mannerisms. ;-)


>> I'd move the imports anyway, whether we separate the functions or not.

> Cool - I'll leave you to do it next edit. I've done a couple of new
> articles for my website (done my Romania blog and part II of my life
> story as articles) - so I'm returning to editing ConfigObj.

Let me know when you're able to let me play with it, too. :-)


> Nice one for the restructuring by the way.

Must... fight... entropy...


>> For my use case, the IP address value is necessary, I wouldn't want to move
>> it to some extra module. So let's keep everything local, at least until
>> there's other stuff to be included that would make the module too unwieldy.

> Ok - do you think it's worth implementing a generic 'regex' test (that
> leaves values as strings), with a standard dict of (any ?) regexes.

Maybe it would, but first I'd like to understand why you ripped'em off
already. ;-)


> Right.. hmm.. trying to fight my way through buzz words. I have a lot of
> respect for Ian Bicking and the WSGI crew. I also like the idea of being
> 'back end independent'.

Modularity is always a good idea, but it's hard, for anyone heavily bent on
multithreading, to earn much respect with me, to put it bluntly.


> I am also reasonably convinced that twisted is the way forward for any
> decent web application - so if they're not compatible... then so be it.

Of the two main strong points of Twisted, I think that the support of many
net protocols is the *least* important one. The concurrency model makes it
a strong base for *any* mid-to-big sized project, that is not enough served
by multiprocessing.


> I'm interested in Nevow... *but* I like the ultra simplicity of
> 'embedded_code'. I don't yet understand what Nevow has to offer that is
> more than templating. In fact most templating languages seem to me just
> another new language (albeit simpler) to avoid embedding python - when
> embedding python code is much more powerful (and I like Python).

You want Quixote's PTLs, man. You *really* want them. :-) What are they?
Text generation through real Python, that's what. BTW, I share your dislike
of embedded mini-languages for templating.

Nevow is much more than templating. The other two main points are form
processing and trasparent page update through Javascript (a superset of the
currently popular Ajax).

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

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

Nicola Larosa wrote:
>>>I'm for consistency (where useful), so I'd use "check" wherever it's
>>>visible to the (programmer) user, either docs or API.
> 
> 
>>The current ConfigObj method is called ``validate`` as it does more than
>>check a single value.
>>I'm adding the ability to check individual values to the ``Section`` - a
>>method I will now call ``check``.
> 
> 
> I take this as a "go ahead" with the "test" -> "check" renaming. :-)
> 

I thought I'd agreed. Anyway - no problem, we've completely broken
backwards compatibility anyway (in lots of good ways - but anything
using the new system is going to have to change code already).

I let Mark Andrews know that there was development work going on, but
never heard back from him. He hasn't blogged for ages either - real life
must be intruding, terrible stuff.

> 
> 
>>On some platforms (like my PDA) importing socket is a non-trivial
>>action. I'm not sure if struct is available for *all* platforms (not all
>>the stdlib is implemented for all platforms - so dependency on a c
>>module for functionality that is unlikely to be used by many users....).
> 
> 
> That's a valid point (and I'd *like* Python on my Palm :-) ).
> 
> 
> 
>>Anyway - it's academic if we move that out into a separate module or
>>move the import statements.
> 
> 
> I'd move the imports anyway, whether we separate the functions or not.
> 

Cool - I'll leave you to do it next edit. I've done a couple of new
articles for my website (done my Romania blog and part II of my life
story as articles) - so I'm returning to editing ConfigObj.

Nice one for the restructuring by the way.

> 
> 
>>>But even before that, I'd place these two methods in a separate "utils.py"
>>>module, and maybe import *them* on demand.
> 
> 
>>I like the idea of keeping it as a single file if we can - but then it's
>>nice to include 'extra' tests that don't need to be part of the core
>>dist. Whatever you think best really.
> 
> 
> For my use case, the IP address value is necessary, I wouldn't want to move
> it to some extra module. So let's keep everything local, at least until
> there's other stuff to be included that would make the module too unwieldy.
> 

Ok - do you think it's worth implementing a generic 'regex' test (that
leaves values as strings), with a standard dict of (any ?) regexes.

> 
> 
>>What I really want is a way into twisted/nevow with WSGI... knowing
>>where to start is the problem.
> 
> 
> AFAIK, there were attempts to give a WSGI interface to Twisted, but it was
> harder than expected. WSGI was mainly thought for multithreaded app
> servers: this is hard to reconcile with Twisted concurrency model, and
> leads to suboptimal results.
> 
> I think that Nevow may work through WSGI, but its native environment is
> direct Twisted.
> 
> I'd like to be proven wrong in all this, of course, but Twisted has this
> tendency to rebuild the world in its image. :-)
> 

Right.. hmm.. trying to fight my way through buzz words. I have a lot of
respect for Ian Bicking and the WSGI crew. I also like the idea of being
'back end independent'.

I am also reasonably convinced that twisted is the way forward for any
decent web application - so if they're not compatible... then so be it.

I'm interested in Nevow... *but* I like the ultra simplicity of
'embedded_code'. I don't yet understand what Nevow has to offer that is
more than templating. In fact most templating languages seem to me just
another new language (albeit simpler) to avoid embedding python - when
embedding python code is much more powerful (and I like Python).

Best Regards,

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

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

>> I'm for consistency (where useful), so I'd use "check" wherever it's
>> visible to the (programmer) user, either docs or API.

> The current ConfigObj method is called ``validate`` as it does more than
> check a single value.
> I'm adding the ability to check individual values to the ``Section`` - a
> method I will now call ``check``.

I take this as a "go ahead" with the "test" -> "check" renaming. :-)


> On some platforms (like my PDA) importing socket is a non-trivial
> action. I'm not sure if struct is available for *all* platforms (not all
> the stdlib is implemented for all platforms - so dependency on a c
> module for functionality that is unlikely to be used by many users....).

That's a valid point (and I'd *like* Python on my Palm :-) ).


> Anyway - it's academic if we move that out into a separate module or
> move the import statements.

I'd move the imports anyway, whether we separate the functions or not.


>> But even before that, I'd place these two methods in a separate "utils.py"
>> module, and maybe import *them* on demand.

> I like the idea of keeping it as a single file if we can - but then it's
> nice to include 'extra' tests that don't need to be part of the core
> dist. Whatever you think best really.

For my use case, the IP address value is necessary, I wouldn't want to move
it to some extra module. So let's keep everything local, at least until
there's other stuff to be included that would make the module too unwieldy.


> What I really want is a way into twisted/nevow with WSGI... knowing
> where to start is the problem.

AFAIK, there were attempts to give a WSGI interface to Twisted, but it was
harder than expected. WSGI was mainly thought for multithreaded app
servers: this is hard to reconcile with Twisted concurrency model, and
leads to suboptimal results.

I think that Nevow may work through WSGI, but its native environment is
direct Twisted.

I'd like to be proven wrong in all this, of course, but Twisted has this
tendency to rebuild the world in its image. :-)

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

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

Nicola Larosa wrote:
>>>This ambiguity of code tests and value tests is tiring me. What if we
>>>called "checks" the value tests, and just "test" the code tests? I'll
>>>shoulder the burden of updating docstrings *and* documentation, if you agree.
> 
> 
>>So tests are the doctests and validate performs 'checks' on values.
>>
>>Ok - *but* are you going to rename the ``Validator.test`` method to
>>``Validator.check`` ?
> 
> 
> Of course. :-)
> 
> 
> 
>>I have to recode the Validator support (and therefore the docs) in
>>ConfigObj anyway - so I'll implement whatever we decide.
> 
> 
> I'm for consistency (where useful), so I'd use "check" wherever it's
> visible to the (programmer) user, either docs or API.
> 

The current ConfigObj method is called ``validate`` as it does more than
check a single value.
I'm adding the ability to check individual values to the ``Section`` - a
method I will now call ``check``.

[snip..]
>>Do you think the ``import socket, struct`` belongs in the body of the
>>module ? This means that importing validate *automatically* imports
>>socket.. a heavy dependency for just one of the checks.
> 
> 
> What's the problem? Isn't it in the std lib anyway?
> 

On some platforms (like my PDA) importing socket is a non-trivial
action. I'm not sure if struct is available for *all* platforms (not all
the stdlib is implemented for all platforms - so dependency on a c
module for functionality that is unlikely to be used by many users....).

Anyway - it's academic if we move that out into a separate module or
move the import statements.


> 
> 
>>How about in the body of the module : ::
>>
>>    socket = None
>>    struct = None
>>
>>In the check :
>>
>>def dottedQuadToNum(ip):
>>    """Convert decimal dotted quad string to long integer"""
>>    global socket, struct
>>    if socket is None:
>>        import socket
>>        import struct
>>
>>and the equivalent in ``numToDottedQuad``.
> 
> 
> I think you can just move the imports inside the functions, without the
> global checking business. Python will take care of that, I don't see
> problems on multiple execution.
> 

Ok

> But even before that, I'd place these two methods in a separate "utils.py"
> module, and maybe import *them* on demand.
> 

I like the idea of keeping it as a single file if we can - but then it's
nice to include 'extra' tests that don't need to be part of the core
dist. Whatever you think best really.

> 
> 
>>Another difficulty - if your config file has an IP address with the
>>relevant check in the configspec then the IP address will be checked and
>>converted to a long using ``dottedQuadToNum``.
>>
>>When you come to write out the config file (by calling ``write`` or
>>``writein`` then the long will be converted using 'str'..... You'd have
>>to call ``numToDottedQuad`` yourself unless we add an alternative
>>mechanism (unvalidation ! - registering a str function as well for each
>>check...)
> 
> 
> Nothing of the sort. Look again at line #876: the long is not actually
> used, the value stays string. ;-D
> 

Ahhh.... ok.

> 
> 
>>Did you see your mention in Daily Python URL ?
> 
> 
> Yes, I did, you sprawled my name all over the place. I'm pleased, of
> course. :-) BTW, the one suggesting Medusa+Quixote was me, again. ;-)
> 

I know, but I thought you'd had enough publicity !

What I really want is a way into twisted/nevow with WSGI... knowing
where to start is the problem.


Regards,

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

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

>> This ambiguity of code tests and value tests is tiring me. What if we
>> called "checks" the value tests, and just "test" the code tests? I'll
>> shoulder the burden of updating docstrings *and* documentation, if you agree.

> So tests are the doctests and validate performs 'checks' on values.
> 
> Ok - *but* are you going to rename the ``Validator.test`` method to
> ``Validator.check`` ?

Of course. :-)


> I have to recode the Validator support (and therefore the docs) in
> ConfigObj anyway - so I'll implement whatever we decide.

I'm for consistency (where useful), so I'd use "check" wherever it's
visible to the (programmer) user, either docs or API.


> I'm liking what you've done with validate.
> Thanks for reformatting the docs as well - writing docs on a PDA is
> *hard* :-)

I am unable to leave well alone what looks even slightly misplaced. ;-)


> Do you think the ``import socket, struct`` belongs in the body of the
> module ? This means that importing validate *automatically* imports
> socket.. a heavy dependency for just one of the checks.

What's the problem? Isn't it in the std lib anyway?


> How about in the body of the module : ::
> 
>     socket = None
>     struct = None
> 
> In the check :
> 
> def dottedQuadToNum(ip):
>     """Convert decimal dotted quad string to long integer"""
>     global socket, struct
>     if socket is None:
>         import socket
>         import struct
> 
> and the equivalent in ``numToDottedQuad``.

I think you can just move the imports inside the functions, without the
global checking business. Python will take care of that, I don't see
problems on multiple execution.

But even before that, I'd place these two methods in a separate "utils.py"
module, and maybe import *them* on demand.


> Another difficulty - if your config file has an IP address with the
> relevant check in the configspec then the IP address will be checked and
> converted to a long using ``dottedQuadToNum``.
> 
> When you come to write out the config file (by calling ``write`` or
> ``writein`` then the long will be converted using 'str'..... You'd have
> to call ``numToDottedQuad`` yourself unless we add an alternative
> mechanism (unvalidation ! - registering a str function as well for each
> check...)

Nothing of the sort. Look again at line #876: the long is not actually
used, the value stays string. ;-D


> Did you see your mention in Daily Python URL ?

Yes, I did, you sprawled my name all over the place. I'm pleased, of
course. :-) BTW, the one suggesting Medusa+Quixote was me, again. ;-)


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

Re: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

Nicola Larosa wrote:
> ...with code tests. Updated the code tests for mixed_list to include IP
> addresses.
> 
> This ambiguity of code tests and value tests is tiring me. What if we
> called "checks" the value tests, and just "test" the code tests? I'll
> shoulder the burden of updating docstrings *and* documentation, if you agree.
> 

So tests are the doctests and validate performs 'checks' on values.

Ok - *but* are you going to rename the ``Validator.test`` method to
``Validator.check`` ?

I have to recode the Validator support (and therefore the docs) in
ConfigObj anyway - so I'll implement whatever we decide.

I'm liking what you've done with validate.
Thanks for reformatting the docs as well - writing docs on a PDA is
*hard* :-)

Do you think the ``import socket, struct`` belongs in the body of the
module ? This means that importing validate *automatically* imports
socket.. a heavy dependency for just one of the checks.

How about in the body of the module : ::

    socket = None
    struct = None

In the check :

def dottedQuadToNum(ip):
    """Convert decimal dotted quad string to long integer"""
    global socket, struct
    if socket is None:
        import socket
        import struct

and the equivalent in ``numToDottedQuad``.


Another difficulty - if your config file has an IP address with the
relevant check in the configspec then the IP address will be checked and
converted to a long using ``dottedQuadToNum``.

When you come to write out the config file (by calling ``write`` or
``writein`` then the long will be converted using 'str'..... You'd have
to call ``numToDottedQuad`` yourself unless we add an alternative
mechanism (unvalidation ! - registering a str function as well for each
check...)

Did you see your mention in Daily Python URL ?

Regards,

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

[Rest2web-develop] Added an 'ip_addr' IPv4 address value test...

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

...with code tests. Updated the code tests for mixed_list to include IP
addresses.

This ambiguity of code tests and value tests is tiring me. What if we
called "checks" the value tests, and just "test" the code tests? I'll
shoulder the burden of updating docstrings *and* documentation, if you agree.

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

Learning C after learning Python can be done via Pyrex. [...]
Learning Java after learning Python can be done via Jython. [...]
Learning Perl after learning Python can ... never mind. ;-)
 -- André Roberge, May 2005

[Rest2web-develop] Reordered configobj4 branch...

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

...to more accurately reflect the trunk; renamed configreader.py back to
configobj.py .

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

Learning C after learning Python can be done via Pyrex. [...]
Learning Java after learning Python can be done via Jython. [...]
Learning Perl after learning Python can ... never mind. ;-)
 -- André Roberge, May 2005

[Rest2web-develop] Added even more tests to validate.py...

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

...and refined the mixed_list check.

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

Learning C after learning Python can be done via Pyrex. [...]
Learning Java after learning Python can be done via Jython. [...]
Learning Perl after learning Python can ... never mind. ;-)
 -- André Roberge, May 2005

Re: [Rest2web-develop] Docs - latest commit

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

> I've just done a commit. I've checked in the cleaned up your cleaned up
> version of the docs for validate and configobj. So at least they are now
> in SVN. I've not done any real work yet.

Got'em.


> Yeah... unfortunately it looks like there is no new work on Epydoc,
> which is worrying for the future.

Among others, the Twisted team uses it, so some bit of maintenance may
still happen.


>> Sure, in their own right they're not trivial, but in the Big Validation
>> Picture, they could appear as polish, maybe. :-)

> Oh - you mean 'coz I've already done all the real work ;-)

Maybe then I should stop doing all this imaginary work... ;-P


>> Yesterday I was looking for Python IDEs (Eric3 is good but its development
>> is not particularly open), looked at DrPython, but summarily dismissed SPE,
>> I don't remember why anymore. I'll have another look at it.

> Right - before this IDLE was my IDE, so I'm probably not used to using
> some of the features you would take for granted.

I'll let you know.

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

Learning C after learning Python can be done via Pyrex. [...]
Learning Java after learning Python can be done via Jython. [...]
Learning Perl after learning Python can ... never mind. ;-)
 -- André Roberge, May 2005

[Rest2web-develop] Docs - latest commit

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

I've just done a commit. I've checked in the cleaned up your cleaned up
version of the docs for validate and configobj. So at least they are now
in SVN. I've not done any real work yet.

Nicola Larosa wrote:

>>Yes - API generation is an interesting subject which I'd like to work on
>>sometimes. Preferably an answer integrated with docutils in some way or
>>other.
>>    
>>
>
>That would be better, but at least Epydoc can read ReST.
>
>  
>
Yeah... unfortunately it looks like there is no new work on Epydoc,
which is worrying for the future.

>  
>
>>There are Epydoc generated docs for ConfigObj 3 online (and in the
>>distro) - and I imagine we'll do the same for ConfigObj 4.
>>    
>>
>
>Great.
>
>
>  
>
>>>More polishing, eh? I'll see what I can do...
>>>      
>>>
>
>  
>
>>Well.... a regex test mechanism is more than polishing (it has to be
>>extensible).
>>
>>Also I suspect timestamp is non trivial but possible.
>>    
>>
>
>Sure, in their own right they're not trivial, but in the Big Validation
>Picture, they could appear as polish, maybe. :-)
>
>
>  
>
Oh - you mean 'coz I've already done all the real work ;-)

>>>P.S.: are you still using, and fixing, DrPython? ;-D
>>>      
>>>
>
>  
>
>>No... SPE is my current IDE. I doubt I will do any development on it
>>though, just with it. I'm growing to appreciate it more and more..
>>    
>>
>
>Yesterday I was looking for Python IDEs (Eric3 is good but its development
>is not particularly open), looked at DrPython, but summarily dismissed SPE,
>I don't remember why anymore. I'll have another look at it.
>
>
>  
>
Right - before this IDLE was my IDE, so I'm probably not used to using
some of the features you would take for granted.

Best Regards,

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

Re: [Rest2web-develop] Re: We forked validate.py

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

> Yes - API generation is an interesting subject which I'd like to work on
> sometimes. Preferably an answer integrated with docutils in some way or
> other.

That would be better, but at least Epydoc can read ReST.


> There are Epydoc generated docs for ConfigObj 3 online (and in the
> distro) - and I imagine we'll do the same for ConfigObj 4.

Great.


>> More polishing, eh? I'll see what I can do...

> Well.... a regex test mechanism is more than polishing (it has to be
> extensible).
> 
> Also I suspect timestamp is non trivial but possible.

Sure, in their own right they're not trivial, but in the Big Validation
Picture, they could appear as polish, maybe. :-)


>> P.S.: are you still using, and fixing, DrPython? ;-D

> No... SPE is my current IDE. I doubt I will do any development on it
> though, just with it. I'm growing to appreciate it more and more..

Yesterday I was looking for Python IDEs (Eric3 is good but its development
is not particularly open), looked at DrPython, but summarily dismissed SPE,
I don't remember why anymore. I'll have another look at it.


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

Learning C after learning Python can be done via Pyrex. [...]
Learning Java after learning Python can be done via Jython. [...]
Learning Perl after learning Python can ... never mind. ;-)
 -- André Roberge, May 2005