-----BEGIN PGP SIGNED MESSAGE----- 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 simplification. >> 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, performance-wise. 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. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHN3s+gerLs4ltQ4RAjytAKCNejjJahOz2Q3seKpE4pcRiZ4TCQCgu+J2 FFeSFhO84s9n25M2p3d0VWQ= =szPr -----END PGP SIGNATURE----- _______________________________________________ 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
