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
