<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">2014-10-14 18:47 GMT+02:00 Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><br></div></div></div><div><br>I'm wondering if a small extension to the WSGI protocol might be sufficient to support this: the special environ variable "wsgi.async_input" could optionally be tied to a standard asyncio stream reader (<a href="https://docs.python.org/3/library/asyncio-stream.html#streamreader" target="_blank">https://docs.python.org/3/library/asyncio-stream.html#streamreader</a>), from which bytes can be read using "yield from stream.read([nbytes])" or "yield from stream.readline()".<br><br></div></div></div></div></div></div></div></blockquote><div><br></div><div>If we support async backends by simply escaping WSGI, don't you feel it kind of make most of the whole discussion moot? </div><div><br></div></div>To me, asyncio already provides a de-facto standard API for asynchronous backends and Tornado/Twisted provide a high level API on top of it. I have to say, I don't precisely grasp what WSGI actually wishes to bring to the table.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As I said in a different thread, most frameworks seem eager to wrap the environ dictionary and hide away all of the WSGI internals (wasting CPU cycles in the process). Is there rationale for continuining down that road?</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br>- Sylvain<br><a href="http://www.defuze.org">http://www.defuze.org</a><br><a href="http://twitter.com/lawouach">http://twitter.com/lawouach</a>
</div></div>