At 06:15 PM 1/8/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO there should be simple support
for obtaining data from wsgi.input.
I'm a bit unclear as to how this will work with async. How do you
propose that an asynchronous application receives the request body?
In my example https://gist.github.com/770743 (which has been
simplified greatly by P.J. Eby in the "Future- and Generator-Based
Async Idea" thread) for dealing with wsgi.input, I have:
future = environ['wsgi.executor'].submit(environ['wsgi.input'].read, 4096)
yield future
While ugly, if you were doing this, you'd likely:
submit = environ['wsgi.executor'].submit
input_ = environ['wsgi.input']
future = yield submit(input_.read, 4096)
data = future.
I don't quite understand the above -- in my sketch, the above would be:
data = yield submit(input._read, 4096)
It looks like your original sketch wants to call .result() on the
future, whereas in my version, the return value of yielding a future
is the result (or an error is thrown if the result was an error).
Is there some reason I'm missing, for why you'd want to explicitly
fetch the result in a separate step?
Meanwhile, thinking about Alex's question, ISTM that if WSGI 2 is
asynchronous, then the wsgi.input object should probably just have
read(), readline() etc. methods that simply return (possibly-mock)
futures. That's *much* better than having to do all that submit()
crud just to read data from wsgi.input().
OTOH, if you want to use the cgi module to parse a form POST from the
input, you're going to need to write an async version of it in that
case, or else feed the entire operation to an executor... but then
the methods would need to be synchronous... *argh*.
I'm starting to not like this idea at all. Alex has actually
pinpointed a very weak spot in the scheme, which is that if
wsgi.input is synchronous, you destroy the asynchrony, but if it's
asynchronous, you can't use it with any normal code that operates on a stream.
I don't see any immediate fixes for this problem, so I'll let it
marinate in the back of my mind for a while. This might be the
achilles heel for the whole idea of a low-rent async WSGI.
_______________________________________________
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
