WSGI and start_response

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Graham Dumpleton-2
On 13 April 2010 20:59, Benoit Chesneau <[hidden email]> wrote:

> On Thu, Apr 8, 2010 at 4:53 PM, P.J. Eby <[hidden email]> 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
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Dirkjan Ochtman
On Tue, Apr 13, 2010 at 13:13, Graham Dumpleton
<[hidden email]> wrote:
> 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. :-)

Do you (or someone else) have a status on where WSGI 2 is? IIRC WSGI 1
isn't really usable with Python 3.x, so it seems about time we get
something going again (AIUI this is blocking Werkzeug from being
ported to 3.x, for example).

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Manlio Perillo-3
Dirkjan Ochtman ha scritto:

> On Tue, Apr 13, 2010 at 13:13, Graham Dumpleton
> <[hidden email]> wrote:
>> 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. :-)
>
> Do you (or someone else) have a status on where WSGI 2 is? IIRC WSGI 1
> isn't really usable with Python 3.x, so it seems about time we get
> something going again (AIUI this is blocking Werkzeug from being
> ported to 3.x, for example).
>

WSGI 2.0 ideas are here:
http://wsgi.org/wsgi/WSGI_2.0

But it does not have support for Python 3.x.

Some corrections to WSGI 1.0 are here:
http://wsgi.org/wsgi/Amendments_1.0


You may add support to Python 3.x in existing WSGI 1.0 implementation,
but your implementation will end up to something that is no more WSGI 1.0.


Manlio
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Graham Dumpleton-2
In reply to this post by Dirkjan Ochtman
On 13 April 2010 21:20, Dirkjan Ochtman <[hidden email]> wrote:

> On Tue, Apr 13, 2010 at 13:13, Graham Dumpleton
> <[hidden email]> wrote:
>> 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. :-)
>
> Do you (or someone else) have a status on where WSGI 2 is? IIRC WSGI 1
> isn't really usable with Python 3.x, so it seems about time we get
> something going again (AIUI this is blocking Werkzeug from being
> ported to 3.x, for example).

WSGI 2.0 isn't about Python 3.X, it is about removing start_response().

Python 3.X support can be catered for by clarifications in the WSGI
1.0 specification and to a degree how Python 3.X is implemented is
dictated by existing practice in the form of what wsgiref implemented
in Python 3.1. The Apache/mod_wsgi implementation has had Python 3.X
support for over a year using the same interpretation. I believe
latest CherryPy WSGI server code is also providing Python 3.X support.

Apache/mod_wsgi tried to push the issue of a new
definition/specification to cater for Python 3.X by actually
identifying itself as WSGI 1.1. The attempts at ratifying that didn't
happen however, but then no one has turned around either to complain
about Apache/mod_wsgi identifying itself as WSGI 1.1 and so it has
been left that way and not reverted to WSGI 1.0.

So, in effect existing practice has determined how WSGI on Python 3.X
should be implemented and given how long this has been going on,
nothing is likely to change that now. You can however see a summary of
how it is being interpreted at:

  http://code.google.com/p/modwsgi/wiki/SupportForPython3X

Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Dirkjan Ochtman
On Tue, Apr 13, 2010 at 13:39, Graham Dumpleton
<[hidden email]> wrote:
> WSGI 2.0 isn't about Python 3.X, it is about removing start_response().

Okay, so it is orthogonal, right?

> Python 3.X support can be catered for by clarifications in the WSGI
> 1.0 specification and to a degree how Python 3.X is implemented is
> dictated by existing practice in the form of what wsgiref implemented
> in Python 3.1. The Apache/mod_wsgi implementation has had Python 3.X
> support for over a year using the same interpretation. I believe
> latest CherryPy WSGI server code is also providing Python 3.X support.
>
> Apache/mod_wsgi tried to push the issue of a new
> definition/specification to cater for Python 3.X by actually
> identifying itself as WSGI 1.1. The attempts at ratifying that didn't
> happen however, but then no one has turned around either to complain
> about Apache/mod_wsgi identifying itself as WSGI 1.1 and so it has
> been left that way and not reverted to WSGI 1.0.
>
> So, in effect existing practice has determined how WSGI on Python 3.X
> should be implemented and given how long this has been going on,
> nothing is likely to change that now. You can however see a summary of
> how it is being interpreted at:
>
>  http://code.google.com/p/modwsgi/wiki/SupportForPython3X

So that page has 8 points required for 3.x, which apparently wsgiref
and CherryPy also adhere to?

And you have 5 simplifications that, as far as we know, have only been
been implemented in mod_wsgi?

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Graham Dumpleton-2
On 13 April 2010 21:46, Dirkjan Ochtman <[hidden email]> wrote:

> On Tue, Apr 13, 2010 at 13:39, Graham Dumpleton
> <[hidden email]> wrote:
>> WSGI 2.0 isn't about Python 3.X, it is about removing start_response().
>
> Okay, so it is orthogonal, right?
>
>> Python 3.X support can be catered for by clarifications in the WSGI
>> 1.0 specification and to a degree how Python 3.X is implemented is
>> dictated by existing practice in the form of what wsgiref implemented
>> in Python 3.1. The Apache/mod_wsgi implementation has had Python 3.X
>> support for over a year using the same interpretation. I believe
>> latest CherryPy WSGI server code is also providing Python 3.X support.
>>
>> Apache/mod_wsgi tried to push the issue of a new
>> definition/specification to cater for Python 3.X by actually
>> identifying itself as WSGI 1.1. The attempts at ratifying that didn't
>> happen however, but then no one has turned around either to complain
>> about Apache/mod_wsgi identifying itself as WSGI 1.1 and so it has
>> been left that way and not reverted to WSGI 1.0.
>>
>> So, in effect existing practice has determined how WSGI on Python 3.X
>> should be implemented and given how long this has been going on,
>> nothing is likely to change that now. You can however see a summary of
>> how it is being interpreted at:
>>
>>  http://code.google.com/p/modwsgi/wiki/SupportForPython3X
>
> So that page has 8 points required for 3.x, which apparently wsgiref
> and CherryPy also adhere to?
>
> And you have 5 simplifications that, as far as we know, have only been
> been implemented in mod_wsgi?

They are not simplications. They are clarifications or just describing
existing practice. They are not necessarily mod_wsgi specific.

(1) Implemented by everyone already otherwise cgi.FieldStorage doesn't work.

(2) Implemented by the more reputable WSGI servers such as CherryPy
and Paste WSGI servers. Not implemented by wsgiref. An implementation
that doesn't implement it and which doesn't discard request content
yet supports HTTP 1.1 request pipelining is arguably broken. A
correctly implemented WSGI middleware already has to cope with an
empty string as end sentinel anyway to detect premature end of input.

(3) Only implemented by Apache/mod_wsgi that I know of for sure.
Although it makes it work like a proper file like object as
specification suggests wsgi.input is, would raise potential issues
with WSGI middleware which depend on it then not being able to be used
with WSGI 1.0 and so intent was that it not be made a requirement.

(4) This is a statement about WSGI middleware, not the WSGI server. A
WSGI middleware that doesn't do it is arguably broken and can generate
incorrect data. Thus is a clarification of obligations only.

(5) A WSGI server shouldn't do this now as doing so is technically a
voilation of HTTP. Thus is a clarification of obligations only.

You can find more detail on these at:

  http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html

Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Dirkjan Ochtman
On Tue, Apr 13, 2010 at 14:01, Graham Dumpleton
<[hidden email]> wrote:
> They are not simplications. They are clarifications or just describing
> existing practice. They are not necessarily mod_wsgi specific.

Sorry, I didn't mean to imply they were mod_wsgi specific, and they
definitely look sane/like an improvement to me.

Okay, so, would it be valuable to have both 1.1 and 2.0? I.e. if we
start writing a new spec now, should we aim for just a 2.0 that copes
with everything at once, or first work on an 1.1 that has
clarifications/improvements and is otherwise relatively compatible
with 1.0 (but also with python 3.x)?

Who's up for some PEP-writing?

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Graham Dumpleton-2
On 13 April 2010 22:12, Dirkjan Ochtman <[hidden email]> wrote:

> On Tue, Apr 13, 2010 at 14:01, Graham Dumpleton
> <[hidden email]> wrote:
>> They are not simplications. They are clarifications or just describing
>> existing practice. They are not necessarily mod_wsgi specific.
>
> Sorry, I didn't mean to imply they were mod_wsgi specific, and they
> definitely look sane/like an improvement to me.
>
> Okay, so, would it be valuable to have both 1.1 and 2.0? I.e. if we
> start writing a new spec now, should we aim for just a 2.0 that copes
> with everything at once, or first work on an 1.1 that has
> clarifications/improvements and is otherwise relatively compatible
> with 1.0 (but also with python 3.x)?
>
> Who's up for some PEP-writing?

The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.

And when I say 'last attempt', yes there have been people who have
stepped up to try and get this to happen in the past. I think you
would be the 3rd time, excluding me in general having tried to push it
in the past and also given up.

You really should perhaps look back through the archive of WEB-SIG
posts on Google Groups to understand the history and how this always
seems to just go around in circles. :-)

Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Dirkjan Ochtman
On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
<[hidden email]> wrote:

> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>
> And when I say 'last attempt', yes there have been people who have
> stepped up to try and get this to happen in the past. I think you
> would be the 3rd time, excluding me in general having tried to push it
> in the past and also given up.
>
> You really should perhaps look back through the archive of WEB-SIG
> posts on Google Groups to understand the history and how this always
> seems to just go around in circles. :-)

I've been on Web-SIG for quite a while now, exactly to keep track of
these issues.

Since there doesn't seem to be much traction, I figured it would be
time to just get a new PEP together. To limit the amount of work, I'd
go in the direction of having a single WSGI 2.0 PEP incorporating your
suggestions (maybe minus the number 3), everything required for Python
3 (as outlined by your wiki page).

The idea is that, as soon as there is a draft PEP, we can circulate it
on Web-SIG for a little bit before bringing it to python-dev. No
single person should really be able to block all this.

I'll try to write something up that incorporates all of your notes.

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Graham Dumpleton-2
On 13 April 2010 23:55, Dirkjan Ochtman <[hidden email]> wrote:

> On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
> <[hidden email]> wrote:
>> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>>
>> And when I say 'last attempt', yes there have been people who have
>> stepped up to try and get this to happen in the past. I think you
>> would be the 3rd time, excluding me in general having tried to push it
>> in the past and also given up.
>>
>> You really should perhaps look back through the archive of WEB-SIG
>> posts on Google Groups to understand the history and how this always
>> seems to just go around in circles. :-)
>
> I've been on Web-SIG for quite a while now, exactly to keep track of
> these issues.
>
> Since there doesn't seem to be much traction, I figured it would be
> time to just get a new PEP together. To limit the amount of work, I'd
> go in the direction of having a single WSGI 2.0 PEP

Limiting your work by going to WSGI 2.0 and dropping start_response()
potentially causes more work for anyone implementing WSGI.

This is because if no official statement about Python 3.X is made
about WSGI 1.0 (with start_response()), and the only option is WSGI
2.0 (without start_response()), people are likely going to be less
inclined to move to Python 3.X for WSGI because to do so means
potentially more drastic changes to their code.

People talk about WSGI 2.0 -> WSGI 1.0 adapters, but if WSGI 1.0 on
Python 3.X is formalised, you can do that.

> incorporating your
> suggestions (maybe minus the number 3), everything required for Python
> 3 (as outlined by your wiki page).

The whole point of not doing (3) in WSGI 1.1 was that it was seen that
it could only be done, if it were to be done, at a point where the API
was broken anyway, ie., when start_response() was dropped in WSGI 2.0.
So, it shouldn't be ruled out in WSGI 2.0 as a possible change. If you
do, then it likely would never be able to be incorporated. So WSGI 2.0
is the only chance to clean that up.

> The idea is that, as soon as there is a draft PEP, we can circulate it
> on Web-SIG for a little bit before bringing it to python-dev. No
> single person should really be able to block all this.
>
> I'll try to write something up that incorporates all of your notes.

Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Manlio Perillo-3
In reply to this post by Dirkjan Ochtman
Dirkjan Ochtman ha scritto:

> On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
> <[hidden email]> wrote:
>> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>>
>> And when I say 'last attempt', yes there have been people who have
>> stepped up to try and get this to happen in the past. I think you
>> would be the 3rd time, excluding me in general having tried to push it
>> in the past and also given up.
>>
>> You really should perhaps look back through the archive of WEB-SIG
>> posts on Google Groups to understand the history and how this always
>> seems to just go around in circles. :-)
>
> I've been on Web-SIG for quite a while now, exactly to keep track of
> these issues.
>
> Since there doesn't seem to be much traction, I figured it would be
> time to just get a new PEP together. To limit the amount of work, I'd
> go in the direction of having a single WSGI 2.0 PEP incorporating your
> suggestions (maybe minus the number 3), everything required for Python
> 3 (as outlined by your wiki page).
>

If you volunteer for this task, I have some suggestions:

* target WSGI 1.1, not WSGI 2.0
* take the original WSGI 1.0 spec text
* start to integrate all changes documented by Graham
* I would really like to have changes integrates as a series of diff,
  using <del> and <ins> HTML elements.

  Unfortunately docutils seems to not have support for this, but should
  not be hard to implement. I can help.
* You should keep a separate, unofficial document, with the rationale of
  the changes.
  You can just copy the content of Graham blog post, and reformatting
  it, if this is ok for Graham
* For each of the main changea, start a thread on this mailing list
  asking for votation.
  If, after 1 week, there is no vote against it, consider it approved


If we are really going to approve WSGI 1.1, I have a request: remove the
``write`` callable.
Rationale:
* it was added in WSGI 1.0 only for compatibility
* new code does not use it
* this will force applications under development that still use the
  ``write`` callable to be fixed. See work on Mercurial
* it is very easy for current implementations to support both WSGI 1.0
  and WSGI 1.1
* legacy application will continue to work
* removing of the ``write`` callable will make middlewares more easy to
  write


Thanks  Manlio
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Graham Dumpleton-2
On 15 April 2010 02:53, Manlio Perillo <[hidden email]> wrote:

> Dirkjan Ochtman ha scritto:
>> On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
>> <[hidden email]> wrote:
>>> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>>>
>>> And when I say 'last attempt', yes there have been people who have
>>> stepped up to try and get this to happen in the past. I think you
>>> would be the 3rd time, excluding me in general having tried to push it
>>> in the past and also given up.
>>>
>>> You really should perhaps look back through the archive of WEB-SIG
>>> posts on Google Groups to understand the history and how this always
>>> seems to just go around in circles. :-)
>>
>> I've been on Web-SIG for quite a while now, exactly to keep track of
>> these issues.
>>
>> Since there doesn't seem to be much traction, I figured it would be
>> time to just get a new PEP together. To limit the amount of work, I'd
>> go in the direction of having a single WSGI 2.0 PEP incorporating your
>> suggestions (maybe minus the number 3), everything required for Python
>> 3 (as outlined by your wiki page).
>>
>
> If you volunteer for this task, I have some suggestions:
>
> * target WSGI 1.1, not WSGI 2.0
> * take the original WSGI 1.0 spec text
> * start to integrate all changes documented by Graham
> * I would really like to have changes integrates as a series of diff,
>  using <del> and <ins> HTML elements.
>
>  Unfortunately docutils seems to not have support for this, but should
>  not be hard to implement. I can help.
> * You should keep a separate, unofficial document, with the rationale of
>  the changes.
>  You can just copy the content of Graham blog post, and reformatting
>  it, if this is ok for Graham
> * For each of the main changea, start a thread on this mailing list
>  asking for votation.
>  If, after 1 week, there is no vote against it, consider it approved
>
>
> If we are really going to approve WSGI 1.1, I have a request: remove the
> ``write`` callable.
> Rationale:
> * it was added in WSGI 1.0 only for compatibility
> * new code does not use it
> * this will force applications under development that still use the
>  ``write`` callable to be fixed. See work on Mercurial
> * it is very easy for current implementations to support both WSGI 1.0
>  and WSGI 1.1
> * legacy application will continue to work
> * removing of the ``write`` callable will make middlewares more easy to
>  write

This is in part why an attempt to come up with a new WSGI 1.X
specification, even one that covers just the obvious and justified
changes because of actual problems, keeps failing. That is, parties
with vested interests or a desire for their little pet change to be
made because it helps them, keep poking their heads up and disrupting
the process.

Given how long this has taken, all that should happen at this point is
a codification of what wsgiref implements for Python 3.X along with
readline() argument change and obvious other clarifications where
actual use shows the original WSGI specification was wrong or where it
wasn't practical.

If that isn't done, we will be here in another year still arguing
about whether some aspect of the specification should be changed or
removed based on some individuals perceived need.

Such a significant change as removing the requirement for write()
should also not be done within a minor version of the WSGI
specification because anything that works with WSGI 1.0 should still
work with WSGI 1.1 and vice versa. On that basis it can't really be
entertained until WSGI 2.0 where incompatible changes would be
allowed.

Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Dirkjan Ochtman
On Thu, Apr 15, 2010 at 01:35, Graham Dumpleton
<[hidden email]> wrote:
> If that isn't done, we will be here in another year still arguing
> about whether some aspect of the specification should be changed or
> removed based on some individuals perceived need.

I agree, WSGI 1.1 should be more like HTML5 in that it tries to more
meticulously describe/unify existing implementations.

> Such a significant change as removing the requirement for write()
> should also not be done within a minor version of the WSGI
> specification because anything that works with WSGI 1.0 should still
> work with WSGI 1.1 and vice versa. On that basis it can't really be
> entertained until WSGI 2.0 where incompatible changes would be
> allowed.

I think it's a good idea to consider for 2.0, certainly.

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Manlio Perillo-3
Dirkjan Ochtman ha scritto:

> [...]
>> Such a significant change as removing the requirement for write()
>> should also not be done within a minor version of the WSGI
>> specification because anything that works with WSGI 1.0 should still
>> work with WSGI 1.1 and vice versa. On that basis it can't really be
>> entertained until WSGI 2.0 where incompatible changes would be
>> allowed.
>
> I think it's a good idea to consider for 2.0, certainly.
>

Ehm, the purpose of WSGI 2.0 is precisely to remove start_response and
write callable with it...


Manlio
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and start_response

Dirkjan Ochtman
On Thu, Apr 15, 2010 at 11:09, Manlio Perillo <[hidden email]> wrote:
> Ehm, the purpose of WSGI 2.0 is precisely to remove start_response and
> write callable with it...

Right, there you go!

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
12