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
