I made a few errors in that massive post...
At 12:00 PM 1/8/2011 -0500, P.J. Eby wrote:
My major concern about the approach is still that it requires a fair
amount of overhead on the part of both app developers and middleware
developers, even if that overhead mostly consists of importing and
decorating. (More below.)
The above turned out to be happily wrong by the end of the post,
since no decorators or imports are actually required for app and
middleware developers.
You can then implement response-processing middleware like this:
def latinize_body(body_iter):
while True:
chunk = yield body_iter
if chunk is None:
break
else:
yield piglatin(yield body_iter)
The last line above is incorrect; it should've been "yield
piglatin(chunk)", i.e.:
def latinize_body(body_iter):
while True:
chunk = yield body_iter
if chunk is None:
break
else:
yield piglatin(chunk)
It's still rather unintuitive, though. There are also plenty of
topics left to discuss, both of the substantial and bikeshedding varieties.
One big open question still in my mind is, are these middleware
idioms any easier to get right than the WSGI 1 ones? For things that
don't process response bodies, the answer seems to be yes: you just
stick in a "yield" and you're done.
For things that DO process response bodies, however, you have to have
ugly loops like the one above.
I suppose it could be argued that, as unintuitive as that
body-processing loop is, it's still orders of magnitude more
intuitive than a piece of WSGI 1 middleware that has to handle both
application yields and write()s!
I suppose my hesitance is due to the fact that it's not as simple as:
return (piglatin(chunk) for chunk in body_iter)
Which is really the level of simplicity that I was looking
for. (IOW, all response-processing middleware pays in this
slightly-added complexity to support the subset of apps and
response-processing middleware that need to wait for events during
body output.)
_______________________________________________
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
