Thread: [Rest2web-develop] Added an 'ip_addr' IPv4 address value test...
Brought to you by:
mjfoord
Menu
▾
▴
rest2web-develop
|
From: Nicola L. <ni...@te...> - 2005-07-20 07:50:08
|
...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 |
|
From: Michael F. <mi...@pc...> - 2005-07-20 08:39:16
|
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
|
|
From: Nicola L. <ni...@te...> - 2005-07-20 09:27:08
|
>> 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 |
|
From: Michael F. <mi...@pc...> - 2005-07-20 09:50:27
|
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 |
|
From: Nicola L. <ni...@te...> - 2005-07-20 10:08:13
|
>> 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 |
|
From: Michael F. <mi...@pc...> - 2005-07-20 11:04:03
|
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 |
|
From: Nicola L. <ni...@te...> - 2005-07-20 12:22:36
|
>> 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 |
|
From: Michael F. <mi...@pc...> - 2005-07-20 13:14:13
|
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). > |
|
From: Nicola L. <ni...@te...> - 2005-07-20 13:50:55
|
> 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X