Guido van Rossum
guido at python.org
Tue Oct 23 16:01:46 CEST 2007
2007/10/22, Ian Bicking <ianb at colorstudy.com>:
> I redid the front page to make it more brief: http://pythonpaste.org/webob/
Much better; I'll try to review it in more detail later. Right now a
few details jump off the page to me: GET and POST are verbs and IMO
poor names for what they represent; params is usually called query
(isn't it?); and what's the advantage of using Request.blank() instead
of simply Request()?
> 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.
The file-serving example has several shortcomings: the presentation
order seems odd, some things are introduced without explanation of
what or why. (Why is UTC imported? Why is mimetypes imported twice?
Why bother with calculating the mime-type at all in the first
example?) Towards the end it seems to go into too many details of
serving up conditional responses and file ranges, which seem better
suited for an advanced manual.
I suggest the wiki-in-one-page would be a better example, even if you
consider it too common (serving static files isn't common? :-).
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Web-SIG