WSGI 1 Changes [ianb's and my changes]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

WSGI 1 Changes [ianb's and my changes]

Armin Ronacher
Hi,

Graham mentioned that the WSGI development might further drift apart
based on the changes Ian Bicking and I did on DjangoCon in a separate hg
repository [1] for the WSGI PEP.

I just want to point out that these are in no way final and are further
intended to only clarify some of the wrong wordings for Python 2, give
us a real readline() function on the input stream and get rid of useless
old cruft such as Python 2.2 support and Jython compatibility which no
longer appears to be a problem.

My personal Idea would be making that PEP WSGI 1.1 and having a separate
one for Python 3.  The reason for pushing up the number would be that
frameworks then can figure out if they have to safely process the input
stream because there is no useful readline function or not.


Regards,
Armin

[1]: http://bitbucket.org/ianb/wsgi-peps/
_______________________________________________
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 1 Changes [ianb's and my changes]

René Dudfield
hi,

I don't like yours and Ians changes with regard to cgi.  cgi exists.
Breaking wsgi apps on cgi is silly.  Especially it is still the only
way to run python web apps on some hosts.  Even though many current
python frameworks are not optimized enough to run on cgi, it is still
used by people.

I think you mean pre-2.2 support, not python 2.2?  iterators came
about in python 2.2.

Fixing the python3 wsgi situation needs to happen very soon(it's been
a year already!).  I don't think delaying it any longer is a good idea
for python 3 and for python as a whole.  So making a separate wsgi
version will not be good if a new wsgi comes out for python3.
_______________________________________________
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 1 Changes [ianb's and my changes]

Armin Ronacher
Hi,

René Dudfield schrieb:
> I don't like yours and Ians changes with regard to cgi.  cgi exists.
> Breaking wsgi apps on cgi is silly.
Can you give an example on where we break CGI compatibility?

> I think you mean pre-2.2 support, not python 2.2?  iterators came
> about in python 2.2.
That might be.  That was before my time.  I'm pretty sure the first
Python version I used was 2.3, but don't quote me on that.

> Fixing the python3 wsgi situation needs to happen very soon(it's been
> a year already!).  I don't think delaying it any longer is a good idea
> for python 3 and for python as a whole.  So making a separate wsgi
> version will not be good if a new wsgi comes out for python3.
I agree that WSGI for Python 3 has to be fixed, I'm just not yet
convinced that Python 3 is what will be relevant anytime soon.  From my
current perspective there is still too much left unanswered in Python 3.


Regards,
Armin

_______________________________________________
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 1 Changes [ianb's and my changes]

ianb
In reply to this post by Armin Ronacher
On Thu, Sep 17, 2009 at 10:57 AM, Armin Ronacher
<[hidden email]> wrote:
> I just want to point out that these are in no way final and are further
> intended to only clarify some of the wrong wordings for Python 2, give
> us a real readline() function on the input stream and get rid of useless
> old cruft such as Python 2.2 support and Jython compatibility which no
> longer appears to be a problem.

To reiterate: people have complained that we've discussed
non-controversial changes to WSGI, but the spec hasn't been updated.
This was in large part, I think, because no one took the step going
from discussion to actual proposed PEP changes.  So these are some
proposed changes, intended to be conservative.  They are meant to be
conservative, more like errata than a real revision, and to reflect
current WSGI practice.  If someone thinks one of the changes goes too
far, then we can discuss -- I think we'll just be more constructive if
we stick to concrete changes to the PEP so we can easily implement
what we all agree on.

--
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker
_______________________________________________
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 1 Changes [ianb's and my changes]

René Dudfield
In reply to this post by Armin Ronacher
Hello,

On Thu, Sep 17, 2009 at 10:48 PM, Armin Ronacher
<[hidden email]> wrote:
> Hi,
>
> René Dudfield schrieb:
>> I don't like yours and Ians changes with regard to cgi.  cgi exists.
>> Breaking wsgi apps on cgi is silly.
> Can you give an example on where we break CGI compatibility?
>

>From this link:  http://bitbucket.org/ianb/wsgi-peps/changeset/b51893478f9a/
It says "Because of this future revisions of WSGI will most likely
switch away from a raw CGI environment to require the server to
provide these values to be quoted and available on a different key."

That sounds like wsgi is breaking cgi... or plans to break cgi.  cgi
is one of those things that just isn't going to die... it's still
useful and used.  I'm not sure if those changes actually break cgi or
not... but that wording sounds like they do.


Also on that link, why not explicitly state that python 2.x should use
str or StringType there?  (line 977).


>> I think you mean pre-2.2 support, not python 2.2?  iterators came
>> about in python 2.2.
> That might be.  That was before my time.  I'm pretty sure the first
> Python version I used was 2.3, but don't quote me on that.

It was definitely 2.2.  So I think that needs to be changed in your
changes - and related changes double checked.
See http://docs.python.org/whatsnew/2.2.html


>
>> Fixing the python3 wsgi situation needs to happen very soon(it's been
>> a year already!).  I don't think delaying it any longer is a good idea
>> for python 3 and for python as a whole.  So making a separate wsgi
>> version will not be good if a new wsgi comes out for python3.
> I agree that WSGI for Python 3 has to be fixed, I'm just not yet
> convinced that Python 3 is what will be relevant anytime soon.  From my
> current perspective there is still too much left unanswered in Python 3.
>

It looks like python3 issues are being addressed in your changes anyway.

Work on python3 building blocks needs to happen soon otherwise it will
hold up lots of people from even porting their code to python3.  wsgi
is one of the main things lagging behind in the python3 porting
effort.

I think both mod_wsgi and cherrypy have worked on issues with python3,
and it seems like there is agreement there on most issues.  So we have
two implementations to play with, and people have more experience with
python3 now... so we should be in a good position to get python3
related changes through quickly.

Thanks for your work on this.

cheers!
_______________________________________________
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 1 Changes [ianb's and my changes]

Graham Dumpleton-2
In reply to this post by Armin Ronacher
2009/9/18 Armin Ronacher <[hidden email]>:

> Hi,
>
> Graham mentioned that the WSGI development might further drift apart
> based on the changes Ian Bicking and I did on DjangoCon in a separate hg
> repository [1] for the WSGI PEP.
>
> I just want to point out that these are in no way final and are further
> intended to only clarify some of the wrong wordings for Python 2, give
> us a real readline() function on the input stream and get rid of useless
> old cruft such as Python 2.2 support and Jython compatibility which no
> longer appears to be a problem.
>
> My personal Idea would be making that PEP WSGI 1.1 and having a separate
> one for Python 3.  The reason for pushing up the number would be that
> frameworks then can figure out if they have to safely process the input
> stream because there is no useful readline function or not.
>
> [1]: http://bitbucket.org/ianb/wsgi-peps/

My concern over seeing the changes is that because no overall plan had
been described by Ian or you as to where you were going in making the
changes, I couldn't see what the end goal was going to be. Thus,
didn't know whether you had a particular end point in mind, ie., a
specific definition of how things should work, or whether you were
just going to incrementally make changes and see what fell out of the
process at the end. I guess I just find it hard to know what you are
trying to do by reading individual changes.

Your comment above about 'having a separate one (specification) for
Python 3' also worries me a bit. That is sort of what I want to avoid.
I would rather we try and use language such that a single
specification would apply meaningfully to all Python versions. I
acknowledge there will still end up being some subtle differences with
how things will work between Python 2.X and Python 3.X, but I don't
think it is enough to warrant a separate specification for Python 3.X,
which in my mind would only confuse things.

So, how about describing your overall master plan? :-)

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 1 Changes [ianb's and my changes]

Armin Ronacher
In reply to this post by René Dudfield
Hi,

René Dudfield schrieb:
> It says "Because of this future revisions of WSGI will most likely
> switch away from a raw CGI environment to require the server to
> provide these values to be quoted and available on a different key."
This information would be additional information of course!

> Also on that link, why not explicitly state that python 2.x should use
> str or StringType there?  (line 977).
Probably a good idea.  Once I'm sure that this i no longer an issue, I
will add that.

> It was definitely 2.2.  So I think that needs to be changed in your
> changes - and related changes double checked.
> See http://docs.python.org/whatsnew/2.2.html
Will do.

> It looks like python3 issues are being addressed in your changes anyway.
But it should be discussed separately and then be integrated.  The
changes in the PEP currently reflect #1 of Graham's proposal.


Regards,
Armin
_______________________________________________
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 1 Changes [ianb's and my changes]

Alan Kennedy-12
In reply to this post by Armin Ronacher
[Rene]
>> I think you mean pre-2.2 support, not python 2.2?  iterators came
>> about in python 2.2.

[Armin]
> That might be.  That was before my time.  I'm pretty sure the first
> Python version I used was 2.3, but don't quote me on that.

As WSGI was being developed, cpython was at version 2.3.

The only reason that support for "older versions" was in the spec was
because jython was at version 2.1 at the time.

The WSGI spec was made much simpler by the use of the iterator
protocol (PEP 234), which was in introduced into the language in 2.2.
So where the spec says

"Supporting Older (<2.2) Versions of Python"

It should probably have read

"Supporting Older (pre-pep-234-iterator-protocol) Versions of Python"

I don't know of any modern python implementation that doesn't support
the iterator protocol.

It's probably time to drop that section from the PEP.

Alan.
_______________________________________________
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