Re: [Web-SIG] httpy -- raise Response(409)
Chad Whitacre wrote: > I think the trick is that in HTTP, success and error conditions both > produce the same result: a Response message. In Python we distinguish > the two: successful "requests" (i.e., function calls) return > something; bad requests raise something. > > So perhaps the answer is that respond(request) may *either* > return *or* raise a Response? This is the approach CherryPy takes. You can raise HTTPRedirect (for 3xx responses) or HTTPError (for 4xx-5xx responses); however, 2xx responses are usually performed with a normal "return". By far, the biggest issue with this approach is educating users: not every *exception* is an *error*. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ 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
Re: [Web-SIG] httpy -- raise Response(409)
On Mon, 27 Feb 2006 12:07:52 -0500, "Chad Whitacre" <[EMAIL PROTECTED]> said: > From conversations this weekend (briefly with Jim; also with Guido) it > seems that the most controversial aspect of httpy's API is the use of > raise for flow control. I wonder if you all wouldn't mind helping me get > to the bottom of this issue? I agree with the general sentiment that raise/except to pass Response objects around feels clunky. > I think the trick is that in HTTP, success and error conditions both > produce the same result: a Response message. In Python we distinguish > the two: successful "requests" (i.e., function calls) return something; > bad requests raise something. If the source of your unease is the handler returning both "success" and "error" responses itself, I'm more comfortable with the abstraction of a handler raising some NotFoundError, for instance, and translating that into a 404 response farther up the stack. (Spyce takes this approach because centralizing exception handling like this makes it easy to allow the user to plug in a custom function to handle them if necessary.) -Jonathan -- C++ is history repeated as tragedy. Java is history repeated as farce. --Scott McKay ___ 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
[Web-SIG] httpy -- raise Response(409)
Dear Web-SIG, First thing's first: >class Responder: > def respond(request): Yes, I forgot 'self'. Sorry. I rushed the announcement out 2.5 hrs before my plane to Dallas took off. BTW, Ian: take that as a +1 for your Python 4k, I guess. :^) Second thing's second: >raise httpy.Response(200, "Greetings, program!") From conversations this weekend (briefly with Jim; also with Guido) it seems that the most controversial aspect of httpy's API is the use of raise for flow control. I wonder if you all wouldn't mind helping me get to the bottom of this issue? (BTW, for background on the project, see here: http://www.zetadev.com/software/httpy/ ) I annoyed Guido at length about why he thought it a bad idea to end transactions with raise, and the answer was that it makes code less readable because you don't know whether to expect a subroutine (that someone else probably wrote) to raise a Response or not. I suggested that this could be documented, but that was thought not to be a strong enough assurance. (Accurate, Guido?) But in fact, isn't this how exceptions work in Python already? There is nothing formal in a function call that indicates what exceptions that call might raise. We rely on the documentation for that, no? I think the trick is that in HTTP, success and error conditions both produce the same result: a Response message. In Python we distinguish the two: successful "requests" (i.e., function calls) return something; bad requests raise something. So perhaps the answer is that respond(request) may *either* return *or* raise a Response? Guido: would that answer your objection? What about the further step of validating the response code for each case (you may only raise a non-2xx Response)? Thanks for the good times this weekend, and for any further thoughts anyone might have. chad ___ 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
