Re: [Web-SIG] WebOb
Guido van Rossum wrote: > 2007/10/22, Ian Bicking <[EMAIL PROTECTED]>: >>> I briefly looked at the tutorial and was put off a little by the >>> interactive prompt style of the examples; that seems so unrealistic >>> that I wonder if it wouldn't be better to just say "put this in a file >>> and run it like this"? >> The side effect of doctesting is that docs sometimes look weird :-/ > > Personally, I find doctest a great tool for writing tests in certain > situations; not so great for writing docs though. Yeah... I really like it in a lot of ways, but I'm not quite sure what the right balance is. Untested documentation is also very unfortunate; too much potential for drift. >> I'm not sure what form the docs should take. I'm open to suggestions. >> The extracted docs are actually reasonable as a reference, I think: >> >> http://pythonpaste.org/webob/class-webob.Request.html >> http://pythonpaste.org/webob/class-webob.Response.html > > Hm, these are mostly alphabetical listings of individual methods and > properties. I'm still hoping for something that I can read from top to > bottom in 10 minutes and get an idea of what this is and how to use > it. I redid the front page to make it more brief: http://pythonpaste.org/webob/ I stopped with the example, because I couldn't think of a good example. Maybe a different evening. Suggestions of course welcome. >> For realistic use cases, some kind of infrastructure is necessary. > > How realistic are we talking? I'm thinking of something that I can > test by pointing my browser to localhost:8080 or similar. For CGI > scripts, the standard library's CGIHTTPServer would suffice. How hard > is it to create something similar for WSGI or for webob? Well, some kind of WSGI adapter; the wsgiref one is fine. The file example I guess is boring, because without some kind of dispatch you can only serve up one file. A most boring server. Wiki is a common example, but a little too common at this point. WebOb doesn't offer anything for HTML either, so it would be a somewhat unsatisfying example anyway I suspect. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Gluon again
On 10/22/07, Massimo Di Pierro <[EMAIL PROTECTED]> wrote: it shows step by step how to build a web app to store recipes and > group them by category. > It is a first draft so there are may be some english some typos. Sorry. I'm going to check this out. Are you from a primarily C background? Your builtin functions look, at least in naming convention, suspiciously like macros. Your controller design seems to borrow heavily from Django, but I suppose that's a good thing. Cheers, I always like to look at new frameworks. Josh -- - http://stderr.ws/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Gluon again
I posted a Gluon tutorial here http://mdp.cti.depaul.edu/examples/static/cookbook.pdf it shows step by step how to build a web app to store recipes and group them by category. It is a first draft so there are may be some english some typos. Sorry. Massimo P.S. I'll never stress it enough. Gluon is GPL2, it is not a commercial product. The reason I am emailing you about this is because I know I can find experts here and I hope you can help me find bugs so that I can fix them and improve Gluons. If there is functionality that you need and you think is not there, just let me know and I will see what I can do. I would also love to see an ajax enthusiast take the challenge to write the first ajax app using Gluon, scriptaculous and json. I do provide some free email support if you sign up on the Gluon google group. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
Adam Atlas wrote: > On 22 Oct 2007, at 12:09, William Dode wrote: > >> So, don't you think web-sig should officialy support such library ? >> Include it in the lib stantard or in a wsgiorg library ? >> > > I don't really like the idea of having something like this be part of > the standard library; it's sort of neither here nor there between low- > level WSGI and framework territory. I don't see people using > something like WebOb to write their applications directly (nor does > that seem to be the intention); just like Paste, it seems more like > something that full frameworks would incorporate and provide access to. I am certainly not representative of a normal developer, but I have been using it quite successfully without any framework. It also provides most of the functionality of WebTest, a framework-neutral functional testing tool, as another example. > Given the principle of "there should be one, and preferably only one, > obvious way to do it", it seems like putting this in the standard > library would be an endorsement of it as the obvious/best way, and > although I like the WebOb approach, I don't think there's enough of a > consensus to bless it thus. For now, the multitude of web frameworks > and their various philosophies is a good thing. After actually reading the APIs of the different request objects and summarizing the differences, I feel much less like this. All the major frameworks (and almost all the minor frameworks) have request and response objects with a subset of the same properties, and some slightly different names. The only really substantial exceptions are Zope and CherryPy that have a bunch of traversal-related properties and methods; but even these have some parallels in WebOb. I've also tried to avoid gratuitous incompatibilities with other frameworks, and to allow backward compatibility through subclassing when there are API differences. There's still some tricky details -- for instance, Django uses a different multi-value dictionary API than WebOb uses. Which is the kind of thing that makes me wish *some* multi-value dictionary API existed in the standard library that could serve as a reasonable model. But so it goes. Even there I switched around WebOb some to be closer to Django (to prefer the last value over the first value, when getting a single value when multiple values are available). As for actual consensus, Pylons is committed to using it and TurboGears by association. Jacob Kaplan-Moss and Simon Willison have expressed specific interest in the idea for Django, though I don't think they've had the time to analyze what that would mean specifically. Jacob Smullyan is also using it as we've heard, and I've heard of some other smaller/internal frameworks using it. That's not consensus, but I think it points to the possibility of consensus. As to the standard library, I don't know, there's a lot of issues with its development model. WebOb, unlike a framework, actually *could* match the kind of slow and steady progress that the standard library has. But the stdlib might be a bad target even so. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
2007/10/22, Ian Bicking <[EMAIL PROTECTED]>: > > I briefly looked at the tutorial and was put off a little by the > > interactive prompt style of the examples; that seems so unrealistic > > that I wonder if it wouldn't be better to just say "put this in a file > > and run it like this"? > > The side effect of doctesting is that docs sometimes look weird :-/ Personally, I find doctest a great tool for writing tests in certain situations; not so great for writing docs though. > I'm not sure what form the docs should take. I'm open to suggestions. > The extracted docs are actually reasonable as a reference, I think: > > http://pythonpaste.org/webob/class-webob.Request.html > http://pythonpaste.org/webob/class-webob.Response.html Hm, these are mostly alphabetical listings of individual methods and properties. I'm still hoping for something that I can read from top to bottom in 10 minutes and get an idea of what this is and how to use it. > For realistic use cases, some kind of infrastructure is necessary. How realistic are we talking? I'm thinking of something that I can test by pointing my browser to localhost:8080 or similar. For CGI scripts, the standard library's CGIHTTPServer would suffice. How hard is it to create something similar for WSGI or for webob? > I suppose a simple example using the wsgiref server and a plain WSGI app > would suffice. Even a very small framework (e.g., > http://svn.pythonpaste.org/Paste/apps/FlatAtomPub/trunk/flatatompub/dec.py) > improves that considerably, but probably isn't worth introducing. It's hard to judge that code since it has zero documentation. I was more looking for something that has a main() which is called when invoked as a script. > >> A quick summary of differences in the API and some other > >> request/response objects out there: > >>http://pythonpaste.org/webob/differences.html > >> I'd include more frameworks, if you can point me to their > >> request/response API documentation (e.g., I looked but couldn't find any > >> for Zope 3). > > > > I'm not too familiar with other frameworks (having always hacked my > > own, as it's so easy :-). Any chance of a summary that's not a > > tutorial nor a reference? > > Did you look at the file serving example? > http://pythonpaste.org/webob/file-example.html Thatr's the first thing I looked at, and that prompted my comments above. :-) > I suppose a quick summary would also be possible, covering just the most > important attributes and with a quick listing of others (like all the > properties for the individual HTTP headers). Yes please. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
On Mon, Oct 22, 2007 at 10:01:52AM -0700, Guido van Rossum wrote: > 2007/8/15, Ian Bicking <[EMAIL PROTECTED]>: > I may be totally behind the times here, but I've always found it odd > to have separate request and response objects -- the functionalities > or APIs don't really overlap, so why not have a single object? I'm > really asking to be educated; I severely hope there's a better reason > than "Java did it this way". :-) I'm hardly in a position to educate you, but here are my two cents. The aging but pleasant framework I've used for years, SkunkWeb (which you are free to think of as the amiable old drunk of the Python web development world) has always had a single Connection object for that reason. However, in skunkweb 4, I tossed it away and switched to using WebOb, because, although I somewhat prefer the aesthetic elegance of having one object rather than two, that preference is very slight, whereas Webob has many other advantages -- to my mind it is superbly done and it would be pointless to rewrite it -- and in fact I made request and response attributes of a single context object, which I suspect many framework authors would do, so instead of CONNECTION.requestHeaders # SkunkWeb 3 I now have Context.request.headers # SkunkWeb 4 which is fine by me. And there are cases when you might want a request or response without really needing the other. For instance, what would be the point of having WebOb's HTTPException classes, which are response subclasses, also be requests? And middleware might not be interested at all in the response -- so why should they deal with an object larded with response-specific attributes, and possibly requiring those attributes to undergo initialization? (Well, there isn't much initialization necessary, I suppose.) Not having to refer to things at times you you don't care about them is an architectural good which offsets to some degree the clumsiness of having two closely related things rather than one when you care about them both. Cheers, js -- Jacob Smullyan ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
Guido van Rossum wrote: >> Anyway, I'd be interested in feedback. We've talked a little about a >> shared request object -- only a little, and I don't know if it is really >> a realistic goal to even try. But I think this request object is a >> considerably higher quality than any other request objects out there. >> The response object provides a nice symmetry, as well as facilitating >> testing. And it's also a very nice response object. > > I may be totally behind the times here, but I've always found it odd > to have separate request and response objects -- the functionalities > or APIs don't really overlap, so why not have a single object? I'm > really asking to be educated; I severely hope there's a better reason > than "Java did it this way". :-) There are several headers that exist in both the request and the response. For instance, Content-Type, Content-Length, and Cache-Control. Additionally, a lot of headers aren't immediately obvious -- is Location a request or response header? Well, response, but if all the headers are mixed together it takes a bit of thought to realize that. The WebOb request and response are mostly representations of the HTTP messages, and there's two distinct messages which look very similar, which makes them hard to mix into one object. >> They are both fairly reasonable to subclass, if there are minor naming >> issues (if there's really missing features, I'd like to add them >> directly -- though for the response object in particular it's likely >> you'll want to subclass to give application defaults, like a default >> content type). >> >> It's based strictly on WSGI, with the request object an almost-stateless >> wrapper around a WSGI environment, and the response object a WSGI >> application that contains mutable status/headers/app_iter. >> >> Almost all the defined HTTP headers are available as attributes on the >> request and/or response. I try to parse these in as sensible a way as >> possible, e.g., req.if_modified_since is a datetime object (of course >> unparsed access is also available). Several objects like >> response.cache_control are a bit more complex, since there's no data >> structure that exactly represents them. I've tried to make them as easy >> to use as possible for realistic web tasks. > > I'm interesting in something that's as lightweight as possible. Are > there things that take a reasonable time to parse that could be put > off until first use? Perhaps using properties to keep the simplest > possible API (or perhaps not to emphasize the cost of first use)? Almost everything is a property. This is in part because state is kept in the native WSGI forms (environ, status, headers, app_iter), so everything is calculated off of these. It also makes instantiation relatively light. Even the request body is left alone until request.POST is accessed. >> I'm very interested to get any feedback, especially right now when there >> are no backward compatibility concerns. Right now no critique is too >> large or small. >> >> It's in svn at: >>http://svn.pythonpaste.org/Paste/WebOb/trunk >> >> And there are fairly complete docs at: >>http://pythonpaste.org/webob/ > > I briefly looked at the tutorial and was put off a little by the > interactive prompt style of the examples; that seems so unrealistic > that I wonder if it wouldn't be better to just say "put this in a file > and run it like this"? The side effect of doctesting is that docs sometimes look weird :-/ I'm not sure what form the docs should take. I'm open to suggestions. The extracted docs are actually reasonable as a reference, I think: http://pythonpaste.org/webob/class-webob.Request.html http://pythonpaste.org/webob/class-webob.Response.html For realistic use cases, some kind of infrastructure is necessary. I suppose a simple example using the wsgiref server and a plain WSGI app would suffice. Even a very small framework (e.g., http://svn.pythonpaste.org/Paste/apps/FlatAtomPub/trunk/flatatompub/dec.py) improves that considerably, but probably isn't worth introducing. >> A quick summary of differences in the API and some other >> request/response objects out there: >>http://pythonpaste.org/webob/differences.html >> I'd include more frameworks, if you can point me to their >> request/response API documentation (e.g., I looked but couldn't find any >> for Zope 3). > > I'm not too familiar with other frameworks (having always hacked my > own, as it's so easy :-). Any chance of a summary that's not a > tutorial nor a reference? Did you look at the file serving example? http://pythonpaste.org/webob/file-example.html I suppose a quick summary would also be possible, covering just the most important attributes and with a quick listing of others (like all the properties for the individual HTTP headers). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers _
Re: [Web-SIG] WebOb
Thanks! I stand educated. 2007/10/22, Jacob Smullyan <[EMAIL PROTECTED]>: > On Mon, Oct 22, 2007 at 10:01:52AM -0700, Guido van Rossum wrote: > > 2007/8/15, Ian Bicking <[EMAIL PROTECTED]>: > > I may be totally behind the times here, but I've always found it odd > > to have separate request and response objects -- the functionalities > > or APIs don't really overlap, so why not have a single object? I'm > > really asking to be educated; I severely hope there's a better reason > > than "Java did it this way". :-) > > I'm hardly in a position to educate you, but here are my two cents. > > The aging but pleasant framework I've used for years, SkunkWeb (which you > are free to think of as the amiable old drunk of the Python web development > world) has always had a single Connection object for that reason. However, > in skunkweb 4, I tossed it away and switched to using WebOb, because, > although I somewhat prefer the aesthetic elegance of having one object > rather than two, that preference is very slight, whereas Webob has many > other advantages -- to my mind it is superbly done and it would be pointless > to rewrite it -- and in fact I made request and response attributes of a > single context object, which I suspect many framework authors would do, so > instead of > >CONNECTION.requestHeaders # SkunkWeb 3 > > I now have > >Context.request.headers # SkunkWeb 4 > > which is fine by me. > > And there are cases when you might want a request or response without really > needing the other. For instance, what would be the point of having WebOb's > HTTPException classes, which are response subclasses, also be requests? And > middleware might not be interested at all in the response -- so why should > they deal with an object larded with response-specific attributes, and > possibly requiring those attributes to undergo initialization? (Well, there > isn't much initialization necessary, I suppose.) Not having to refer to > things at times you you don't care about them is an architectural good which > offsets to some degree the clumsiness of having two closely related things > rather than one when you care about them both. > > > Cheers, > > js > > -- > Jacob Smullyan > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: > Cool. I already heard in the grapevibe about webob.py. > >> Anyway, I'd be interested in feedback. We've talked a little about a >> shared request object -- only a little, and I don't know if it is really >> a realistic goal to even try. But I think this request object is a >> considerably higher quality than any other request objects out there. >> The response object provides a nice symmetry, as well as facilitating >> testing. And it's also a very nice response object. > > I may be totally behind the times here, but I've always found it odd > to have separate request and response objects -- the functionalities > or APIs don't really overlap, so why not have a single object? I'm > really asking to be educated; I severely hope there's a better reason > than "Java did it this way". :-) HTTP has both headers and payload supplied by the client and returned by the server: not mixing them up is probably the driving reason for keeping separate objects. Of course, you could make one object with 'request' and 'response' attributes, but that wouldn't really be a simplification. >> They are both fairly reasonable to subclass, if there are minor naming >> issues (if there's really missing features, I'd like to add them >> directly -- though for the response object in particular it's likely >> you'll want to subclass to give application defaults, like a default >> content type). >> >> It's based strictly on WSGI, with the request object an almost-stateless >> wrapper around a WSGI environment, and the response object a WSGI >> application that contains mutable status/headers/app_iter. >> >> Almost all the defined HTTP headers are available as attributes on the >> request and/or response. I try to parse these in as sensible a way as >> possible, e.g., req.if_modified_since is a datetime object (of course >> unparsed access is also available). Several objects like >> response.cache_control are a bit more complex, since there's no data >> structure that exactly represents them. I've tried to make them as easy >> to use as possible for realistic web tasks. > > I'm interesting in something that's as lightweight as possible. Are > there things that take a reasonable time to parse that could be put > off until first use? Perhaps using properties to keep the simplest > possible API (or perhaps not to emphasize the cost of first use)? The only big parsing load is going to be the request payload; processing top-level request headers is normally trivial, performance-wise. I read Ian's concern as being about an API for setting / updating cache-control response headers[1], because he found no natural mapping for them as Python primitives. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHN3s+gerLs4ltQ4RAjytAKCNejjJahOz2Q3seKpE4pcRiZ4TCQCgu+J2 FFeSFhO84s9n25M2p3d0VWQ= =szPr -END PGP SIGNATURE- ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
On 22 Oct 2007, at 12:09, William Dode wrote: > So, don't you think web-sig should officialy support such library ? > Include it in the lib stantard or in a wsgiorg library ? > I don't really like the idea of having something like this be part of the standard library; it's sort of neither here nor there between low- level WSGI and framework territory. I don't see people using something like WebOb to write their applications directly (nor does that seem to be the intention); just like Paste, it seems more like something that full frameworks would incorporate and provide access to. Given the principle of "there should be one, and preferably only one, obvious way to do it", it seems like putting this in the standard library would be an endorsement of it as the obvious/best way, and although I like the WebOb approach, I don't think there's enough of a consensus to bless it thus. For now, the multitude of web frameworks and their various philosophies is a good thing. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
2007/8/15, Ian Bicking <[EMAIL PROTECTED]>: > Lately I got on a kick and extracted/refined/reimplemented a bunch of > stuff from Paste. The result is the not-quite-released WebOb (I don't > want to do a release until I think people should use it instead of > Paste, to the degree the two overlap -- and it's not *quite* ready for > that). Cool. I already heard in the grapevibe about webob.py. > Anyway, I'd be interested in feedback. We've talked a little about a > shared request object -- only a little, and I don't know if it is really > a realistic goal to even try. But I think this request object is a > considerably higher quality than any other request objects out there. > The response object provides a nice symmetry, as well as facilitating > testing. And it's also a very nice response object. I may be totally behind the times here, but I've always found it odd to have separate request and response objects -- the functionalities or APIs don't really overlap, so why not have a single object? I'm really asking to be educated; I severely hope there's a better reason than "Java did it this way". :-) > They are both fairly reasonable to subclass, if there are minor naming > issues (if there's really missing features, I'd like to add them > directly -- though for the response object in particular it's likely > you'll want to subclass to give application defaults, like a default > content type). > > It's based strictly on WSGI, with the request object an almost-stateless > wrapper around a WSGI environment, and the response object a WSGI > application that contains mutable status/headers/app_iter. > > Almost all the defined HTTP headers are available as attributes on the > request and/or response. I try to parse these in as sensible a way as > possible, e.g., req.if_modified_since is a datetime object (of course > unparsed access is also available). Several objects like > response.cache_control are a bit more complex, since there's no data > structure that exactly represents them. I've tried to make them as easy > to use as possible for realistic web tasks. I'm interesting in something that's as lightweight as possible. Are there things that take a reasonable time to parse that could be put off until first use? Perhaps using properties to keep the simplest possible API (or perhaps not to emphasize the cost of first use)? > I'm very interested to get any feedback, especially right now when there > are no backward compatibility concerns. Right now no critique is too > large or small. > > It's in svn at: >http://svn.pythonpaste.org/Paste/WebOb/trunk > > And there are fairly complete docs at: >http://pythonpaste.org/webob/ I briefly looked at the tutorial and was put off a little by the interactive prompt style of the examples; that seems so unrealistic that I wonder if it wouldn't be better to just say "put this in a file and run it like this"? > A quick summary of differences in the API and some other > request/response objects out there: >http://pythonpaste.org/webob/differences.html > I'd include more frameworks, if you can point me to their > request/response API documentation (e.g., I looked but couldn't find any > for Zope 3). I'm not too familiar with other frameworks (having always hacked my own, as it's so easy :-). Any chance of a summary that's not a tutorial nor a reference? > WebOb has a lot more methods and attributes than other libraries, but > this document points out only things where there are differing names or > things not in WebOb. Most other such objects also don't have the same > WSGI-oriented scope (with the exception of Yaro and paste.wsgiwrappers). > > The Request and Response API (extracted docs): >http://pythonpaste.org/webob/class-webob.Request.html >http://pythonpaste.org/webob/class-webob.Response.html -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
On 10/22/07, William Dode <[EMAIL PROTECTED]> wrote: > So, don't you think web-sig should officialy support such library ? > Include it in the lib stantard or in a wsgiorg library ? I'm strongly against adding more non-Python-runtime batteries to the standard library. The plethora of packages already there makes updating individual libraries to get bug fixes or features quite painful. This has nothing to do with WebOb in particular; I've not had a chance to look at that yet. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
William Dode ha scritto: > Hi, > > Since the announce of ian about webob, i did two things with it. > > First i include it in my personal web framework, it was very easy, i had > just to remove all my crappy equivalent functions. It make my framework > a little bit more clean and i can inherit new features. > > Second, most important, i wanted to start a little project without any > framework to minimize the dependencies. So i started from scratch only > with WebOb, the wsgiref server and a part of the example in routing_args > specifications. It did it very quickly and the result should be > compatible with any wsgi compliant pieces. > > So, don't you think web-sig should officialy support such library ? > Include it in the lib stantard or in a wsgiorg library ? > > Waiting for your view... > I think that, first of all, we should standardize the utility functions for headers handling (parsing and serializing). Regards Manlio Perillo ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WebOb
Hi, Since the announce of ian about webob, i did two things with it. First i include it in my personal web framework, it was very easy, i had just to remove all my crappy equivalent functions. It make my framework a little bit more clean and i can inherit new features. Second, most important, i wanted to start a little project without any framework to minimize the dependencies. So i started from scratch only with WebOb, the wsgiref server and a part of the example in routing_args specifications. It did it very quickly and the result should be compatible with any wsgi compliant pieces. So, don't you think web-sig should officialy support such library ? Include it in the lib stantard or in a wsgiorg library ? Waiting for your view... -- William Dodé - http://flibuste.net Informaticien indépendant I've hard to write in english language... please don't hesitate to give me somes advices in private ! ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
