[Web-SIG] WebOb

[Guido van Rossum]

Thanks! I stand educated.

2007/10/22, Jacob Smullyan <smulloni at smullyan.org>:
> On Mon, Oct 22, 2007 at 10:01:52AM -0700, Guido van Rossum wrote:
> > 2007/8/15, Ian Bicking <ianb at colorstudy.com>:
> > 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/)