[Web-SIG] WebOb

Tres Seaver tseaver at palladion.com
Mon Oct 22 19:29:17 CEST 2007

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

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

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 Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Web-SIG mailing list