[Web-SIG] WebOb

[Guido van Rossum]

2007/8/15, Ian Bicking <ianb at colorstudy.com>:
> 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/)