On May 7, 2008, at 4:44 AM, Manlio Perillo wrote:
Moreover I don't see any readons to have a revc method instead of
read.
I just wanted to emphasize that its behavior is socket-like, not file-
like. It could be called read as long as its behavior is made clear
to application developers.
Unfortunately there is a *big* usability problem: the extension is
based on a well specified feature of WSGI: the gateway can suspend
the execution of the WSGI application when it yields.
However if the asynchronous code is present in a "child" function,
we have something like this:
...
That is, all the functions in the "chain" have to yield, and is
not very good.
Yes, you're right. However, if you're willing/able to use Python
2.5, you can use the new features of generators to implement a call
stack that lets you call child functions and receive return values
and exceptions from them. I've implemented this in
awsgiref.callstack. Have a look at
http://pseudogreen.org/bzr/awsgiref/examples/echo_request_with_callstack.py
for an example of how it works.
I don't think this will solve the problem.
Moreover in your example you buffer the whole request body so that
you have to yield only one time.
Your example was:
def application(environ, start_response):
def nested():
while True:
poll(xxx)
yield ''
yield result
for r in nested():
if not r:
yield ''
yield r
My suggestion would allow you to rewrite this like so:
@awsgiref.callstack.add_callstack
def application(environ, start_response):
def nested():
while True:
poll(xxx)
yield ''
yield result
yield nested()
The nesting can be arbitrarily deep, so nested() could yield
doubly_nested() and so on. While not as elegant as greenlets, I think
this does address your concern.
The main problem I see with greenlet is that is is not yet stable
(there are some problems with the garbage collector) and that is is
not part of CPython.
This means that it can be not acceptable to write a PEP for a WSGI
like interface with coroutine support.
This is the problem I see with greenlets, too. If they were part of
the stdlib, it'd be a different story, but as things stand, I don't
think they should be part of the spec.
Chris
_______________________________________________
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
