[Web-SIG] httpy -- raise Response(409)

[Chad Whitacre]

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