[Web-SIG] WSGI and start_response

[Graham Dumpleton]

On 13 April 2010 20:59, Benoit Chesneau <bchesneau at gmail.com> wrote:
> On Thu, Apr 8, 2010 at 4:53 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 04:08 PM 4/8/2010 +0200, Manlio Perillo wrote:
>>>
>>> Hi.
>>>
>>> Some time ago I objected the decision to remove start_response function
>>> from next version WSGI, using as rationale the fact that without
>>> start_callable, asynchronous extension are impossible to support.
>>>
>>> Now I have found that removing start_response will also make impossible
>>> to support coroutines (or, at least, some coroutines usage).
>>>
>>> Here is an example (this is the same example I posted few days ago):
>>> http://paste.pocoo.org/show/199202/
>>>
>>> Forgetting about the write callable, the problem is that the application
>>> starts to yield data when tmpl.render_unicode function is called.
>>>
>>> Please note that this has *nothing* to do with asynchronus applications.
>>> The code should work with *all* WSGI implementations.
>>>
>>>
>>> In the pasted example, the Mako render_unicode function is "turned" into
>>> a generator, with a simple function that allows to flush the current
>>> buffer.
>>>
>>>
>>> Can someone else confirm that this code is impossible to support in WSGI
>>> 2.0?
>>
>> I don't understand why it's a problem.  See my previous post here:
>>
>> http://mail.python.org/pipermail/web-sig/2009-September/003986.html
>>
>> for a sketch of a WSGI 1-to-2 converter.  It takes a WSGI 1 application
>> callable as the input, and returns a WSGI 2 function.
>>
> where is WSGI 2 pep ? I would like to see it first rather than seeig
> different implementations.

There is no such thing as a WSGI 2.0 PEP and there is no proper
concensus either on what it should look like. Thus if you see anything
claiming to implement WSGI 2.0, then it isn't and you should only view
it as an experimental proposal. You are warned. :-)

Graham