Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
On Mon, Sep 21, 2009 at 1:28 AM, Armin Ronacher wrote: > If it was just that I would be happy to stay with bytes. But unless the > standard library changes in the way it works on Python 3 there is not > much but unicode we can use. bytes no longer behave like strings, it's > not very comfortable to work with them. Indeed. Hence my comments about WSGI leaking up into other code. Now that bytes and strings are incompatible, a lot of code which relied on (arguably) a wart in Python will break. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
Hi, James Bennett schrieb: > Well, ordinarily I'd be inclined to agree: HTTP deals in bytes, so an > interface to HTTP should deal in bytes as well. If it was just that I would be happy to stay with bytes. But unless the standard library changes in the way it works on Python 3 there is not much but unicode we can use. bytes no longer behave like strings, it's not very comfortable to work with them. Regards, Armin ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
On Sun, Sep 20, 2009 at 11:25 PM, Chris McDonough wrote: > WSGI is a fairly low-level protocol aimed at folks who need to interface a > server to the outside world. The outside world (by its nature) talks bytes. > I fear that any implied conversion of environment values and iterable > return values to Unicode will actually eventually make things harder than > they are now. I realize that it would make middleware implementors lives > harder to need to deal in bytes. However, at this point, I also believe > that middleware kinda should be hard. We have way too much middleware that > shouldn't be middleware these days (some written by myself). Well, ordinarily I'd be inclined to agree: HTTP deals in bytes, so an interface to HTTP should deal in bytes as well. The problem, really is that despite being a very low-level interface, WSGI has a tendency to leak up into much higher-level code, and (IMO) authors of that high-level code really shouldn't have to waste their time dealing with details of the underlying low-level gateway. You've said you don't want to hear "Python 3" as the reason, but it provides some useful examples: in high-level code you'll commonly want to be doing things like, say, comparing parts of the requested URL path to known strings or patterns. And that high-level code will almost certainly use strings, while WSGI, in theory, will be using bytes. That's just a recipe for disaster; if WSGI mandates bytes, then bytes will have to start "infecting" much higher-level code (since Python 3 -- rightly -- doesn't let you be nearly as promiscuous about mixing bytes and strings). Once I'm at a point where I can use Python 3, I know I'll personally be looking for some library which will normalize everything for me before I interact with it, precisely to avoid this sort of leakage; if WSGI itself would at least *allow* that normalization to happen at the low level (mandating it is another discussion entirely) I'd feel much happier about it going forward. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
Hi, Robert Brewer schrieb: > urllib.unquote, for one. We had to make a version which accepts bytes > (and outputs bytes). But it's only 8 lines of code. Here a patch for urllib.parse that restores Python 2.x behavior. Because it also changes behavior for Python 3.x I have not yet submitted it for discussions: http://paste.pocoo.org/show/140739/ This adds byte support for all unquoting functions and URL parsing and joining. It also changes the quoting functions to return bytes when passed bytes. The latter is something that most likely does not survive a review on python-dev. Regards, Armin ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
Hi, Chris McDonough schrieb: > Personally, I find it a bit hard to get excited about Python 3 as a web > application deployment platform. Everybody feels that way currently. But if we don't fix WSGI that will never change. > Given this point of view, it would be extremely helpful if someone could > explain to people with the same outlook why we should want to deal with > Unicode > strings in any WSGI specification. I summarized the reasons in my mail. Also have a look at the discussions in this mailinglist that lead to that. Regards, Armin ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
+1 On Sep 20, 2009, at 11:25 PM, Chris McDonough wrote: I'll try to digest some of this, currently I'm pretty clueless. Personally, I find it a bit hard to get excited about Python 3 as a web application deployment platform. This is of course a personal judgment (I don't mean to slight Python 3) but at this point, I'll think I'll probably be writing software that targets 2.X exclusively for at least the next five years. Given this point of view, it would be extremely helpful if someone could explain to people with the same outlook why we should want to deal with Unicode strings in any WSGI specification. WSGI is a fairly low-level protocol aimed at folks who need to interface a server to the outside world. The outside world (by its nature) talks bytes. I fear that any implied conversion of environment values and iterable return values to Unicode will actually eventually make things harder than they are now. I realize that it would make middleware implementors lives harder to need to deal in bytes. However, at this point, I also believe that middleware kinda should be hard. We have way too much middleware that shouldn't be middleware these days (some written by myself). Anyway, for us slower (and maybe wrongly fearful) folks, could someone summarize the benefits of having a WSGI specification that requires Unicode. Bonus points for an explanation that does not boil down to "it will be compatible with Python 3". - C Armin Ronacher wrote: Hello everybody, Thanks to Graham Dumpleton and Robert Brewer there is some serious progress on WSGI currently. I proposed a roadmap with some PEP changes now that need some input. Summary: WSGI 1.0 stays the same as PEP 0333 currently is WSGI 1.1 becomes what Ian and I added to PEP 0333 WSGI 2.0 becomes a unicode powered version of WSGI 1.1 WSGI 3.0 becomes WSGI 2.0 just without start_response WSGI 1.0 and 1.1 are byte based and nearly impossible to use on Python 3 because of changes in the standard library that no longer work with a byte-only approach. The PEPs themselves are here: http://bitbucket.org/ianb/wsgi-peps/ Neither the wording not the changes in there are anywhere near final. Graham wrote down two questions he wants every major framework developer to be answered. These should guide the way to new WSGI standards: 1. Do we keep bytes everywhere forever in Python 2.X, or try to introduce unicode there at all to at least mirror what changes might be made to make WSGI workable in Python 3.X? 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to WSGI 2.0 for Python 3.X? I added a new question I think should be asked too: 3. Do we skip WSGI 2.0 as specified in the PEP and go straight to WSGI 3.0 and drop start_response? The following things became pretty clear when playing around with various specifications on Python 3: - Python 3 no longer implicitly converts between unicode and byte strings. This covers comparisons, the regular expression engine, all string functions and many modules in the stdlib. - The Python 3 stdlib radically moved to unicode for non unicode things as well (the http servers, http clients, url handling etc.) - A byte only version of WSGI appears unrealistic on Python 3 because it would require server and middleware implementors to reimplement parts of the standard library to work on bytes again. - unicode support can be added for WSGI on both Python 2.x and Python 3.x without removing functionality. Browsers are already doing a similar encoding trick as proposed by Graham Dumpleton to handle URLs. - Python 2.x already accepts unicode strings for many things such as URL handling thanks to the fact that unicode and byte strings are surprisingly interchangeable. - cgi.FieldStorage and some other parts is now totally broken on Python 3 and should no longer be used in 3.0 and 3.1 because it reads the response body into memory. This currently affects WebOb, Pylons and TurboGears. I sent this mail to every major framework / WSGI implementor so that we get input even if you're missing the discussion on web-sig. Regards, Armin ___ 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/chrism%40plope.com ___ 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/mdipierro%40cs.depaul.edu ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
I'll try to digest some of this, currently I'm pretty clueless. Personally, I find it a bit hard to get excited about Python 3 as a web application deployment platform. This is of course a personal judgment (I don't mean to slight Python 3) but at this point, I'll think I'll probably be writing software that targets 2.X exclusively for at least the next five years. Given this point of view, it would be extremely helpful if someone could explain to people with the same outlook why we should want to deal with Unicode strings in any WSGI specification. WSGI is a fairly low-level protocol aimed at folks who need to interface a server to the outside world. The outside world (by its nature) talks bytes. I fear that any implied conversion of environment values and iterable return values to Unicode will actually eventually make things harder than they are now. I realize that it would make middleware implementors lives harder to need to deal in bytes. However, at this point, I also believe that middleware kinda should be hard. We have way too much middleware that shouldn't be middleware these days (some written by myself). Anyway, for us slower (and maybe wrongly fearful) folks, could someone summarize the benefits of having a WSGI specification that requires Unicode. Bonus points for an explanation that does not boil down to "it will be compatible with Python 3". - C Armin Ronacher wrote: Hello everybody, Thanks to Graham Dumpleton and Robert Brewer there is some serious progress on WSGI currently. I proposed a roadmap with some PEP changes now that need some input. Summary: WSGI 1.0 stays the same as PEP 0333 currently is WSGI 1.1 becomes what Ian and I added to PEP 0333 WSGI 2.0 becomes a unicode powered version of WSGI 1.1 WSGI 3.0 becomes WSGI 2.0 just without start_response WSGI 1.0 and 1.1 are byte based and nearly impossible to use on Python 3 because of changes in the standard library that no longer work with a byte-only approach. The PEPs themselves are here: http://bitbucket.org/ianb/wsgi-peps/ Neither the wording not the changes in there are anywhere near final. Graham wrote down two questions he wants every major framework developer to be answered. These should guide the way to new WSGI standards: 1. Do we keep bytes everywhere forever in Python 2.X, or try to introduce unicode there at all to at least mirror what changes might be made to make WSGI workable in Python 3.X? 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to WSGI 2.0 for Python 3.X? I added a new question I think should be asked too: 3. Do we skip WSGI 2.0 as specified in the PEP and go straight to WSGI 3.0 and drop start_response? The following things became pretty clear when playing around with various specifications on Python 3: - Python 3 no longer implicitly converts between unicode and byte strings. This covers comparisons, the regular expression engine, all string functions and many modules in the stdlib. - The Python 3 stdlib radically moved to unicode for non unicode things as well (the http servers, http clients, url handling etc.) - A byte only version of WSGI appears unrealistic on Python 3 because it would require server and middleware implementors to reimplement parts of the standard library to work on bytes again. - unicode support can be added for WSGI on both Python 2.x and Python 3.x without removing functionality. Browsers are already doing a similar encoding trick as proposed by Graham Dumpleton to handle URLs. - Python 2.x already accepts unicode strings for many things such as URL handling thanks to the fact that unicode and byte strings are surprisingly interchangeable. - cgi.FieldStorage and some other parts is now totally broken on Python 3 and should no longer be used in 3.0 and 3.1 because it reads the response body into memory. This currently affects WebOb, Pylons and TurboGears. I sent this mail to every major framework / WSGI implementor so that we get input even if you're missing the discussion on web-sig. Regards, Armin ___ 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/chrism%40plope.com ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
P.J. Eby wrote: > At 03:06 PM 9/20/2009 +0200, Armin Ronacher wrote: > >The following things became pretty clear when playing around with > >various specifications on Python 3: > > > >- Python 3 no longer implicitly converts between unicode and byte > >strings. This covers comparisons, the regular expression engine, > >all string functions and many modules in the stdlib. > >- The Python 3 stdlib radically moved to unicode for non unicode > things > >as well (the http servers, http clients, url handling etc.) > > > >- A byte only version of WSGI appears unrealistic on Python 3 because > >it would require server and middleware implementors to reimplement > >parts of the standard library to work on bytes again. > > IMO, this strongly suggests that it's the stdlib or Python 3 that's > broken here. How much of the stdlib are we talking about needing to > reimplement, aside from cgi.FieldStorage? urllib.unquote, for one. We had to make a version which accepts bytes (and outputs bytes). But it's only 8 lines of code. Robert Brewer fuman...@aminus.org ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
Graham Dumpleton wrote: > Looking at the bigger picture, there are three overall goals that I > can see that we would want to address. > > 1. Clarifications and corrections to existing WSGI for Python 2.X to > allow readline() with size hint, mandatory end of stream sentinel for > wsgi.input, support for chunked request content and rules on amount of > data that should be returned by WSGI applications and how much data > wsg.file_wrapper should send back from a file when Content-Length is > defined. These were the points (11) to (16) that I tacked onto my > definition #4, in my blog post. They are applicable though to any > update to WSGI for any version of Python. > > 2. Come up with a version of WSGI for Python 3.X. The whole bytes > versus unicode discussion. > > 3. Drop the start_response() function and ability to use its write() > function returned as result. What people have been calling WSGI 2.0. My goals, in priority order, for the next version(s) of WSGI: 1. Full unicode (not just x00-xFF) in Python 3 for the environ keys and most values (not wsgi.input, for example). 2. Points 11-16 as you described. 3. The ability to upgrade a WSGI1.0/CPython2.x application to CPython3 using 2to3, minimizing ancillary changes, even if that means requiring an upgrade to the WSGI version in the process. 4. Minimize the special cases in any new spec. Note this is at the lowest priority. > To go along with that, there are a couple major questions I think > needs to be answered and this will dictate to a degree what any > roadmap will be. > > The first question is, should Python 2.X forever be bytes everywhere, > or if we start introducing unicode into parts of the definition for > Python 3.X, should those versions of the WSGI specification map those > unicode parts back in to the Python 2.X of an equivalent version of > the specification? CherryPy 3.x on Python 2.x will always use bytes everywhere, as we have always done. So I understand completely if Django, Pylons, etc have "always used" unicode and want to keep doing that. If y'all decide to make a version of WSGI which requires unicode because you think it's easier or more popular, no problem--CherryPy 3.2+ on Python 2 will just convert back to bytes before handing off that data to CherryPy apps. This is one reason why a new "wsgi.url_encoding" entry would be required if SCRIPT_NAME/PATH_INFO/QUERY_STRING become unicode. > In my definitions I introduced 'native' string along with 'bytes' and > 'unicode' string in an attempt to try and be able to use one set of > language which would describe WSGI and be interpretable in the context > of both Python 2.X and Python 3.X. > > For definition #4, this mean defining SCRIPT_NAME, PATH_INFO and > QUERY_STRING as 'unicode' string. This meant that for Python 2.X, they > would as such also be unicode string. The other option was to define > them as 'native' string, which means the whole 'wsgi.uri_encoding' > flag was only relevant to Python 3.X, as in Python 2.X the native > string is 'bytes' and so the whole encoding issue would still be up to > the WSGI application as it is now for bytes everywhere WSGI in Python > 2.X. In effect, if they were 'native' strings and 'wsgi.uri_encoding' > went way, we just have existing WSGI 1.0. The only actual difference > was that I was adding on top of definition #4 the clarifications as > per (1) above. I'd be happy if WSGI 1.1 said "use native" and the "wsgi.uri_encoding" entry was only required on versions of Python where the native string type is unicode. That's an extra paragraph in the spec, yes, so violates my goal 4 a bit, but IMO should not outweigh my goals 1, 2, and 3. > The second question is, do we want to try and come up with something > for Python 3.X, ie., (2) above, while still preserving the current > start_response() callback, or do we instead want to jump direct to > WSGI (Python 3.X) 2.0, ie., combine (2) and (3) above, and say that > there is no WSGI 1.X for Python 3.X at all? I want something in between so I don't have to wait months or years for WSGI 2. I want to ship a version of CherryPy with Python 3 support last week. Robert Brewer fuman...@aminus.org ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
Armin Ronacher wrote: > Thanks to Graham Dumpleton and Robert Brewer there is some serious > progress on WSGI currently. I proposed a roadmap with some PEP changes > now that need some input. > > Summary: > > WSGI 1.0 stays the same as PEP 0333 currently is > WSGI 1.1 becomes what Ian and I added to PEP 0333 > WSGI 2.0 becomes a unicode powered version of WSGI 1.1 > WSGI 3.0 becomes WSGI 2.0 just without start_response > > WSGI 1.0 and 1.1 are byte based and nearly impossible to use on > Python > 3 because of changes in the standard library that no longer work with > a byte-only approach. > > > The PEPs themselves are here: http://bitbucket.org/ianb/wsgi-peps/ > Neither the wording not the changes in there are anywhere near final. > > > Graham wrote down two questions he wants every major framework > developer > to be answered. These should guide the way to new WSGI standards: > > 1. Do we keep bytes everywhere forever in Python 2.X, or try to >introduce unicode there at all to at least mirror what changes might >be made to make WSGI workable in Python 3.X? I'm happy either way, since CherryPy abstracts it all away. Decide already and I'll implement it. > 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to >WSGI 2.0 for Python 3.X? +1 for skipping straight to unicode in Python 3. But call it "1.1" not "2.0". > I added a new question I think should be asked too: > > 3. Do we skip WSGI 2.0 as specified in the PEP and go straight to >WSGI 3.0 and drop start_response? No. We need more time to discuss and try to implement the large architectural changes in that. I need to ship CP 3.2 soon and would like it to have a better Python 3 story than the "bytes-everywhere" (or "unicode pretending to be bytes") of WSGI 1.0. We have working code, which uses unicode in Python 3. Maybe I'll call it "wsgi.version = (1, 'cp32')" and let the spec come later if we can't see the trees for the forest. Robert Brewer fuman...@aminus.org ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
2009/9/21 P.J. Eby : > At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote: >> >> Good plan but I'm afraid now only a bunch of elite people on this list >> is going to remember all the details on theses "upcoming" >> specifications. Why the rush to specify WSGI 3.0 and not focus >> mainly on the next one ahead ? > > Because having more versions of the spec is a bug, not a feature. How many > versions will a server or framework be reasonably expected to support? I think there is perhaps two aspects to the original question about why even project ahead to WSGI 3.0 (no start_response) at this point. The first is why we want to even be considering dropping start_response at all at this point if people see the current way of doing things as reasonable. The second is whether any effort in drafting a new specification can be avoided at all by going direct to WSGI 3.0, combining amendments, going unicode and dropping start_response all in one go. I have a few views on this. The first is that although I probably have the most difficult job to implement multiple WSGI versions, given that mod_wsgi is all in C code with no Python code at all, the changes we are talking about at the moment aren't that drastic that can't relatively easily support multiple WSGI versions. In fact, mod_wsgi already implements what we are talking about in WSGI 1.1. This is because WSGI 1.1 is more about providing guarantees to the WSGI application based on how the majority of WSGI adapters/servers already work. I would expect it will be even simpler for WSGI adapters/servers implemented in pure Python to cope with multiple versions. In respect of defining all the versions now as a well defined roadmap, from the adapter/server side, you need to realise that existing implementations have become quite stable. As such, the frequency of any updates to them is going to get larger and larger. For me, I would rather add in the support for WSGI 1.1/2.0/3.0 now, knowing that likely might not make another major version release of mod_wsgi for a year or more, if at all. If mod_wsgi is stable and ends up don't see a need to go and implement further new features I have speculated on, then I don't want to come back in a year just to add WSGI 3.0 support. Further, given that Python 3.X is going to be a trigger point for people to at least make changes to unicode, it would be nice to have WSGI 3.0 out there as a separate additional step they can consider at the same time. Ultimately I feel it will be the general masses and not WSGI adapter/server implementers who will make the decision about how big a jump they will want to make. Enforcing a jump to WSGI 3.0 may not be looked on favourably given that that is a much more significant change. Think of all the problems with migration to Python 3.X as far as people waiting for third party modules to be updated. You will see the same problem with WSGI components if we go direct to WSGI 3.0. As WSGI 2.0 for Python 2.X is, due to way bytes/unicode can still be used interchangeably, it is a much simpler transition and I can see a quick movement to that, or even for the WSGI components to work with all of WSGI 1.0/1.1/2.0 at the same time. For many, if they are smart about it, they may even be able to easily support WSGI 3.0 as well at same time as 1.0/1.1/2.0. The key here would probably be us defining prototype skeletons for code which exhibits how supporting multiple versions in WSGI components could be done easily. As to the idea that going direct to WSGI 3.0 will save us some work in drafting any specification at least, I don't see that it will on the basis that at the moment the only difference we are talking about between WSGI 2.0/3.0 is dropping of start_response(). This is because bits of the other stuff already talked about in relation to what we were calling WSGI 2.0 previously, is already a part of what we are now saying is WSGI 1.1/2.0. In other words, the only important thing that has got deferred to WSGI 3.0 is dropping of start_response(). Some of the other comments seem to indicate that perhaps some have much more drastic changes in mind than just that. If you do, then perhaps you want to outline what those other changes may be so can gauge how significant they are. Even if people decide to only go as far as WSGI 2.0 at this point, I would still likely implement WSGI 3.0 as an experimental feature just so people can play with it directly rather than have to fiddle with adapters. It wouldn't be the default version anyway, so its present isn't going to affect the general population. BTW, Python 2.6 can itself be seen as a transitional version in some ways between Python 2.5 and Python 3.0. So, not like the idea of WSGI 2.0 being a transitional version is unique. :-) Graham ___ 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.co
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
2009/9/21 Armin Ronacher : >> IMO, this strongly suggests that it's the stdlib or Python 3 that's >> broken here. How much of the stdlib are we talking about needing to >> reimplement, aside from cgi.FieldStorage? > I'm already creating a patch for urllib which currently requires > unicode. I'm not sure about what to do with cgi.FieldStorage, in > general I would not recommend using the cgi module for WSGI applications > at all! If we would go with bytes for the WSGI 1.0 spec on Python 3 a > WSGI server also has to decode that data from the Server again. > > Also (something I haven't yet filed as a bug because I guess there will > be more changes involved) the HTTP server in Python 3.1 does not support > non-ASCII headers. Read the following first: http://bugs.python.org/issue4953 http://bugs.python.org/issue4661 There the ones I know about that affect cgi.FieldStorage. Graham ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
P.J. Eby schrieb: >>- Python 3 no longer implicitly converts between unicode and byte >>strings. This covers comparisons, the regular expression engine, >>all string functions and many modules in the stdlib. >>- The Python 3 stdlib radically moved to unicode for non unicode things >>as well (the http servers, http clients, url handling etc.) >> >>- A byte only version of WSGI appears unrealistic on Python 3 because >>it would require server and middleware implementors to reimplement >>parts of the standard library to work on bytes again. > > IMO, this strongly suggests that it's the stdlib or Python 3 that's > broken here. How much of the stdlib are we talking about needing to > reimplement, aside from cgi.FieldStorage? FWIW, it's very much possible that the py3k stdlib is broken there. Many modules were "ported" with the aim "get the test running again", and not too much thought about bytes/unicode issues. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
At 04:50 PM 9/20/2009 +0200, Armin Ronacher wrote:
Django, Pylons, SQLAlchemy, Mako, Jinja2, Genshi, Werkzeug, WebOb and
many more technologies are based on unicode, even in Python 2.x. They
are currently doing decoding of byte data internally.
In Python 2.x if we stick to native strings for WSGI 2.0 / 1.5 whatever
we suddenly have different code paths for Python 3 and Python 2.
Because in Python 3 we suddendly already have unicode data.
No, you'd have bytes stored in a latin-1 string, which is not quite
the same thing as "already [having] unicode data". You have to
.encode('latin1').decode(targetencoding) if you want genuine unicode data.
If you're saying that people's code would have to change when they go
to Python 3 (i.e., adding the extra .encode()), I think that's
already a given for *any* non-trivial code, not just WSGI.
> IMO, this strongly suggests that it's the stdlib or Python 3 that's
> broken here. How much of the stdlib are we talking about needing to
> reimplement, aside from cgi.FieldStorage?
I'm already creating a patch for urllib which currently requires
unicode. I'm not sure about what to do with cgi.FieldStorage, in
general I would not recommend using the cgi module for WSGI applications
at all!
But people do, in fact, use it for WSGI on 2.x, so if having
"different code paths" is a problem, certainly dropping the cgi
module is at least as big of a problem, if not considerably more so.
I think one of the reasons that the current (and ongoing) PEP
discussions have been foundering is that there isn't a clear
delineation of goals at the high level, and rather just a bunch of
tradeoff discussions, absent any criteria by which to make the tradeoffs.
To me, I'd rather see people port to a new WSGI spec (with a new
calling convention) on Python 2, and only *then* transition to Python
3. If we do that well, then the intermediate pain disappears -- as
does the pain and complexity of trying to make a bastardized
in-between specification. ;-)
Truth be told, we can probably do that new spec *faster* if we don't
have to worry too much about backward compatibility, and just design
it for the way things are now, instead of worrying about the
past. Even if we have to do some odd things inside a 2-to-1
converter, there should ideally only have to be a handful of such
converters ever written.
___
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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
On Sun, Sep 20, 2009 at 3:51 PM, P.J. Eby wrote: > At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote: >> >> Good plan but I'm afraid now only a bunch of elite people on this list >> is going to remember all the details on theses "upcoming" >> specifications. Why the rush to specify WSGI 3.0 and not focus >> mainly on the next one ahead ? > > Because having more versions of the spec is a bug, not a feature. How many > versions will a server or framework be reasonably expected to support? > > Also, note that changing the calling convention ensures that you can't > accidentally run an old application with a server that will be sending it > different information than it expects. This ensures that we can have clean > boundary conditions between spec versions, and can hopefully just have a > few, well-tested and battle-hardened converters. > +1 for one new version with different behaviour. ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
Hi, P.J. Eby schrieb: > This discussion has been going on for so long that I've already > forgotten what the problem was with just using the original 1.0 spec > for 3.X, i.e., using native strings for everything, using latin-1 > encoding. The only things I can recall off the top of my head are > that the input stream would still be bytes, and that the environment > might've used a different encoding. Django, Pylons, SQLAlchemy, Mako, Jinja2, Genshi, Werkzeug, WebOb and many more technologies are based on unicode, even in Python 2.x. They are currently doing decoding of byte data internally. In Python 2.x if we stick to native strings for WSGI 2.0 / 1.5 whatever we suddenly have different code paths for Python 3 and Python 2. Because in Python 3 we suddendly already have unicode data. You're assuming a situation where the applicaiton in Python 2.x was byte based, but in the majority of cases this is never the situation. > IMO, this strongly suggests that it's the stdlib or Python 3 that's > broken here. How much of the stdlib are we talking about needing to > reimplement, aside from cgi.FieldStorage? I'm already creating a patch for urllib which currently requires unicode. I'm not sure about what to do with cgi.FieldStorage, in general I would not recommend using the cgi module for WSGI applications at all! If we would go with bytes for the WSGI 1.0 spec on Python 3 a WSGI server also has to decode that data from the Server again. Also (something I haven't yet filed as a bug because I guess there will be more changes involved) the HTTP server in Python 3.1 does not support non-ASCII headers. Regards, Armin ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote: Good plan but I'm afraid now only a bunch of elite people on this list is going to remember all the details on theses "upcoming" specifications. Why the rush to specify WSGI 3.0 and not focus mainly on the next one ahead ? Because having more versions of the spec is a bug, not a feature. How many versions will a server or framework be reasonably expected to support? Also, note that changing the calling convention ensures that you can't accidentally run an old application with a server that will be sending it different information than it expects. This ensures that we can have clean boundary conditions between spec versions, and can hopefully just have a few, well-tested and battle-hardened converters. ___ 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
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
At 03:06 PM 9/20/2009 +0200, Armin Ronacher wrote: Hello everybody, Thanks to Graham Dumpleton and Robert Brewer there is some serious progress on WSGI currently. I proposed a roadmap with some PEP changes now that need some input. Summary: WSGI 1.0 stays the same as PEP 0333 currently is WSGI 1.1 becomes what Ian and I added to PEP 0333 WSGI 2.0 becomes a unicode powered version of WSGI 1.1 WSGI 3.0 becomes WSGI 2.0 just without start_response Since there's already a well-established notion of WSGI 2.0 being the new calling convention, I would suggest (to avoid confusion) renaming your "2.0" to "1.2" or "1.5" or something instead. WSGI 1.0 and 1.1 are byte based and nearly impossible to use on Python 3 because of changes in the standard library that no longer work with a byte-only approach. This is unfortunate, but it should probably be considered a bellwether for Python 3 porting in general, alas. The Python 3 stdlib *should* work with bytes, and the fact that it does not should be treated as a bug in the stdlib rather than something to be worked around in WSGI. Graham wrote down two questions he wants every major framework developer to be answered. These should guide the way to new WSGI standards: 1. Do we keep bytes everywhere forever in Python 2.X, or try to introduce unicode there at all to at least mirror what changes might be made to make WSGI workable in Python 3.X? Technically, we are not using bytes but "native" strings, i.e. type 'str'. What benefit would introducing unicode produce? 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to WSGI 2.0 for Python 3.X? This discussion has been going on for so long that I've already forgotten what the problem was with just using the original 1.0 spec for 3.X, i.e., using native strings for everything, using latin-1 encoding. The only things I can recall off the top of my head are that the input stream would still be bytes, and that the environment might've used a different encoding. I don't know if such an approach should actually be *recommended*, but having a migration path for WSGI 1.0-> Python 3.X sounds like a good idea, if it can be done strictly as errata/clarification of the existing spec. Otherwise, might as well forget the whole thing and go straight to the latest and greatest (i.e. what has previously been called 2.0 and you're calling 3.0.) I added a new question I think should be asked too: 3. Do we skip WSGI 2.0 as specified in the PEP and go straight to WSGI 3.0 and drop start_response? I suggest skipping straight to the latest and greatest with no in-betweens at all, other than errata/clarifications on 1.0. Having lots of variations of a "standard" is a bug, not a feature! The following things became pretty clear when playing around with various specifications on Python 3: - Python 3 no longer implicitly converts between unicode and byte strings. This covers comparisons, the regular expression engine, all string functions and many modules in the stdlib. - The Python 3 stdlib radically moved to unicode for non unicode things as well (the http servers, http clients, url handling etc.) - A byte only version of WSGI appears unrealistic on Python 3 because it would require server and middleware implementors to reimplement parts of the standard library to work on bytes again. IMO, this strongly suggests that it's the stdlib or Python 3 that's broken here. How much of the stdlib are we talking about needing to reimplement, aside from cgi.FieldStorage? ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
2009/9/20 Armin Ronacher : > Hi, > > I know I pretty much SPAM the list here now which is why I added all the > changes of WSGI 1.0 and what could become WSGI 1.1 into a repo on > bitbucket as two PEPS: > > http://bitbucket.org/ianb/wsgi-peps/src/ > > > pep-0333.txt > > This is basically just a new revision for PEP 333 changing the following > things: > > - removing Jython and Python 2.2 compatibility. Jython is close enough > to modern Python versions now that this does not make any difference. > > - fixing wsgi.input by adding a proper readline(). The current version > still requires the user to care about not reading past the content > length, but if all server implementors agree that could be changed so > that the stream provides an end of line marker. > > - mentioning that WSGI 1.0 is not supported by Python 3. > > - made WSGI 1.0 depend on bytes. > > - fixed example code > > - servers may no longer add a date or server header if that header is > already present. (This MUST may become a SHOULD for the server > header as it's probably hard to control for things like mod_wsgi) > > - weakened the rules for buffering and streaming. Everybody does it, > so it should be allowed. > > - added middleware warning for `wsgi.file_wrapper` > > > pep-.txt > > This specifies WSGI 1.1 based on #3/#4 in Graham Dumpletons Blog post. > The differences to his proposal: > > - the application iterator must by byte based. I would really require > that, so that people explicitly encode their stuff as utf-8 instead > of yielding latin1. If we want to allow unicode return values I > strongly encourage using utf-8 for the return value because we already > require UTF-8 URLs. > > - clarified wsgi.uri_encoding, that algorithm should not be the default > but the only one to make it easier for applications to reencode URIs. > > - Stick to `start_response` and `exc_info` but add deprecation warnings > for `exc_info` and `write()`. This should make it easier to port > applications over. Breaking too many APIs at the same time is > probably not the best idea. > > > If we really want to get rid of `start_response` at the same time, I > would suggest using ``(appiter, status, headers)`` instead of > ``(status, headers, appiter)``. The former is the current common > signature of response objects which would make it possible to convert > from a WSGI application response to a response object by doing something > like this: > > response = Response(*wsgi_app(request.environ)) > > The PEP is currently missing any copyright information and headers > and should only be considered as a draft. Regardless of the details of changes being made to the PEP and the creation of any new ones, do we need to first agree on the overall direction we are going to take. Ie., the grand plan at a high level. What I am getting at here is that the likes of PJE has indicated a preference for skipping any WSGI 1.1 altogether and going straight to WSGI 2.0. If there isn't going to be support all round for even coming out with WSGI 1.1, then don't want to see time wasted trying to come up with a new PEP only for what is needed to change. I actually suggested going straight to WSGI 2.0 back the start of last year and got chastised for making the suggestion. The criticisms back then were because I was saying that since people were going to have to make changes for Python 3.0 anyway, why not enforce an API change at the same time. This didn't go down too well with those who wanted to promote 2to3 as the way of migrating to Python 3.0, even though I was already pointing out that WSGI as it was probably wasn't going to work on Python 3.0. Our own ongoing discussions have proved out that point and that some change will be required to make it usable. I do acknowledge though that I wanted to skip WSGI 1.X altogether for Python 3.0, where as PJE is trying to install his preferred definition #3, and one he has always promoted from day one, as WSGI 1.0 for Python 3.X, even though it doesn't comply with WSGI PEP and by rights shouldn't be called WSGI 1.0. So, I am starting to get nervous that we could go to a great deal of work to try and resolve the various issues for a specific definition, only to find that people don't even agree that such a version is warranted and we get a deadlock. Looking at the bigger picture, there are three overall goals that I can see that we would want to address. 1. Clarifications and corrections to existing WSGI for Python 2.X to allow readline() with size hint, mandatory end of stream sentinel for wsgi.input, support for chunked request content and rules on amount of data that should be returned by WSGI applications and how much data wsg.file_wrapper should send back from a file when Content-Length is defined. These were the points (11) to (16) that I tacked onto my definition #4, in my blog post. They are applicable though to any update to WSGI for any version of Python. 2. Come up with a version of WSGI
[Web-SIG] Request for Comments on upcoming WSGI Changes
Hello everybody, Thanks to Graham Dumpleton and Robert Brewer there is some serious progress on WSGI currently. I proposed a roadmap with some PEP changes now that need some input. Summary: WSGI 1.0 stays the same as PEP 0333 currently is WSGI 1.1 becomes what Ian and I added to PEP 0333 WSGI 2.0 becomes a unicode powered version of WSGI 1.1 WSGI 3.0 becomes WSGI 2.0 just without start_response WSGI 1.0 and 1.1 are byte based and nearly impossible to use on Python 3 because of changes in the standard library that no longer work with a byte-only approach. The PEPs themselves are here: http://bitbucket.org/ianb/wsgi-peps/ Neither the wording not the changes in there are anywhere near final. Graham wrote down two questions he wants every major framework developer to be answered. These should guide the way to new WSGI standards: 1. Do we keep bytes everywhere forever in Python 2.X, or try to introduce unicode there at all to at least mirror what changes might be made to make WSGI workable in Python 3.X? 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to WSGI 2.0 for Python 3.X? I added a new question I think should be asked too: 3. Do we skip WSGI 2.0 as specified in the PEP and go straight to WSGI 3.0 and drop start_response? The following things became pretty clear when playing around with various specifications on Python 3: - Python 3 no longer implicitly converts between unicode and byte strings. This covers comparisons, the regular expression engine, all string functions and many modules in the stdlib. - The Python 3 stdlib radically moved to unicode for non unicode things as well (the http servers, http clients, url handling etc.) - A byte only version of WSGI appears unrealistic on Python 3 because it would require server and middleware implementors to reimplement parts of the standard library to work on bytes again. - unicode support can be added for WSGI on both Python 2.x and Python 3.x without removing functionality. Browsers are already doing a similar encoding trick as proposed by Graham Dumpleton to handle URLs. - Python 2.x already accepts unicode strings for many things such as URL handling thanks to the fact that unicode and byte strings are surprisingly interchangeable. - cgi.FieldStorage and some other parts is now totally broken on Python 3 and should no longer be used in 3.0 and 3.1 because it reads the response body into memory. This currently affects WebOb, Pylons and TurboGears. I sent this mail to every major framework / WSGI implementor so that we get input even if you're missing the discussion on web-sig. Regards, Armin ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Armin Ronacher wrote: > Hi, > > Graham Dumpleton schrieb: >> Regardless of the details of changes being made to the PEP and the >> creation of any new ones, do we need to first agree on the overall >> direction we are going to take. Ie., the grand plan at a high level. > Indeed. The 0333 changes are mostly uncontroversial and can be > discovered separately. So far the discussions on this mailinglist in > the last days only covered what would be a new WSGI version which is in > the file. > >> What I am getting at here is that the likes of PJE has indicated a >> preference for skipping any WSGI 1.1 altogether and going straight to >> WSGI 2.0. If there isn't going to be support all round for even coming >> out with WSGI 1.1, then don't want to see time wasted trying to come >> up with a new PEP only for what is needed to change. > The time wasted on is not that much, it's just your #3 written down > to text with the unicode return values. > >> So, I am starting to get nervous that we could go to a great deal of >> work to try and resolve the various issues for a specific definition, >> only to find that people don't even agree that such a version is >> warranted and we get a deadlock. > WSGI 1.1 as currently specified in would be pretty uncontroversial > on Python 2.x because of the str/unicode coercion that Python implicitly > applies and that this is basically the only change. > >> 1. Clarifications and corrections to existing WSGI for Python 2.X > Is already in 0333 in the repository. > >> 2. Come up with a version of WSGI for Python 3.X. The whole bytes >> versus unicode discussion. > That is in , just that this new version of WSGI also works in Python > 2.x and is unicode based. > >> 3. Drop the start_response() function and ability to use its write() >> function returned as result. What people have been calling WSGI 2.0. > That would be too many changes at the same time. We can specify WSGI > 2.0 at the same time based on and just change the return value to > ``(app_iter, status, headers)`` and drop the `start_response`. But that > really breaks applications and workflows and I don't think everybody > would swtich over to that right away. > >> The first question is, should Python 2.X forever be bytes everywhere, >> or if we start introducing unicode [...] > Latest version of specifies ist as unicode for 2.x and 3.x except > where native strings still make sense. > >> In my definitions I introduced 'native' string along with 'bytes' and >> 'unicode' string in an attempt to try and be able to use one set of >> language which would describe WSGI and be interpretable in the context >> of both Python 2.X and Python 3.X. > is basically that. > >> The second question is, do we want to try and come up with something >> for Python 3.X, ie., (2) above, while still preserving the current >> start_response() callback, or do we instead want to jump direct to >> WSGI (Python 3.X) 2.0, ie., combine (2) and (3) above, and say that >> there is no WSGI 1.X for Python 3.X at all? > does not drop start_response. That would break too much code (all > middlewares and it's not straightforward to write middlewares for both > start_response and without then). > >> For example, one option for a roadmap would keep bytes everywhere in >> Python 2.X and jump direct to WSGI 2.0 in Python 3.X. > IMO WSGI 1.0 should just fix the small problem it has, and WSGI 1.1 goes > to unicode in both versions. > >> WSGI (Python 2.X) 1.1 - Clarify existing WSGI by adding (1) above. >> WSGI (Python 2.X) 2.0 - Drop start_response() from WSGI (Python 2.X) >> 1.1. Keep bytes everywhere. >> WSGI (Python 3.X) 2.0 - Adapt WSGI (Python 2.X) 2.0 to Python 3.X. Use >> definition #4 (or more likely a variation on it). > For that I would rather go like this: > > WSGI 1.0 stays the same as PEP 0333 currently is > WSGI 1.1 becomes what Ian and I added to PEP 0333 > WSGI 2.0 becomes a modified version of PEP > WSGI 3.0 like XXX but drops start_response Good plan but I'm afraid now only a bunch of elite people on this list is going to remember all the details on theses "upcoming" specifications. Why the rush to specify WSGI 3.0 and not focus mainly on the next one ahead ? With regards, Etienne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq2JIYACgkQ/VP9MZjcTlePlwCfQKKjLp0ZUyObFJvYbUHIARdY sqwAoJ99JgdKaIVjw5SZfXveFS+tSj7/ =VHY9 -END PGP SIGNATURE- ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
2009/9/20 Armin Ronacher : > For that I would rather go like this: > > WSGI 1.0 stays the same as PEP 0333 currently is > WSGI 1.1 becomes what Ian and I added to PEP 0333 > WSGI 2.0 becomes a modified version of PEP > WSGI 3.0 like XXX but drops start_response > > > ... > >> 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to >> WSGI 2.0 for Python 3.X? > Yes. Except that when I meant WSGI 2.0, I meant without start_response. You instead bump dropping that out to WSGI 3.0, which is fine. Okay, you just followed up with those clarifications anyway. :-) Graham ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
Hi, Armin Ronacher schrieb: > WSGI 1.1 as currently specified in would be pretty uncontroversial > on Python 2.x because of the str/unicode coercion that Python implicitly > applies and that this is basically the only change. Based on the table, is 2.0 now. > That would be too many changes at the same time. We can specify WSGI > 2.0 at the same time based on Would be 3.0 then. > IMO WSGI 1.0 should just fix the small problem it has, and WSGI 1.1 goes > to unicode in both versions. Based on the table. 1.0 is 1.1 and 1.1 is 2.0. I hope that unconfuses my mail, but I'm pretty sure it did not :) Regards, Armin ___ 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
Re: [Web-SIG] PEP 0333 and PEP XXXX Updated
Hi, Graham Dumpleton schrieb: > Regardless of the details of changes being made to the PEP and the > creation of any new ones, do we need to first agree on the overall > direction we are going to take. Ie., the grand plan at a high level. Indeed. The 0333 changes are mostly uncontroversial and can be discovered separately. So far the discussions on this mailinglist in the last days only covered what would be a new WSGI version which is in the file. > What I am getting at here is that the likes of PJE has indicated a > preference for skipping any WSGI 1.1 altogether and going straight to > WSGI 2.0. If there isn't going to be support all round for even coming > out with WSGI 1.1, then don't want to see time wasted trying to come > up with a new PEP only for what is needed to change. The time wasted on is not that much, it's just your #3 written down to text with the unicode return values. > So, I am starting to get nervous that we could go to a great deal of > work to try and resolve the various issues for a specific definition, > only to find that people don't even agree that such a version is > warranted and we get a deadlock. WSGI 1.1 as currently specified in would be pretty uncontroversial on Python 2.x because of the str/unicode coercion that Python implicitly applies and that this is basically the only change. > 1. Clarifications and corrections to existing WSGI for Python 2.X Is already in 0333 in the repository. > 2. Come up with a version of WSGI for Python 3.X. The whole bytes > versus unicode discussion. That is in , just that this new version of WSGI also works in Python 2.x and is unicode based. > 3. Drop the start_response() function and ability to use its write() > function returned as result. What people have been calling WSGI 2.0. That would be too many changes at the same time. We can specify WSGI 2.0 at the same time based on and just change the return value to ``(app_iter, status, headers)`` and drop the `start_response`. But that really breaks applications and workflows and I don't think everybody would swtich over to that right away. > The first question is, should Python 2.X forever be bytes everywhere, > or if we start introducing unicode [...] Latest version of specifies ist as unicode for 2.x and 3.x except where native strings still make sense. > In my definitions I introduced 'native' string along with 'bytes' and > 'unicode' string in an attempt to try and be able to use one set of > language which would describe WSGI and be interpretable in the context > of both Python 2.X and Python 3.X. is basically that. > The second question is, do we want to try and come up with something > for Python 3.X, ie., (2) above, while still preserving the current > start_response() callback, or do we instead want to jump direct to > WSGI (Python 3.X) 2.0, ie., combine (2) and (3) above, and say that > there is no WSGI 1.X for Python 3.X at all? does not drop start_response. That would break too much code (all middlewares and it's not straightforward to write middlewares for both start_response and without then). > For example, one option for a roadmap would keep bytes everywhere in > Python 2.X and jump direct to WSGI 2.0 in Python 3.X. IMO WSGI 1.0 should just fix the small problem it has, and WSGI 1.1 goes to unicode in both versions. > WSGI (Python 2.X) 1.1 - Clarify existing WSGI by adding (1) above. > WSGI (Python 2.X) 2.0 - Drop start_response() from WSGI (Python 2.X) > 1.1. Keep bytes everywhere. > WSGI (Python 3.X) 2.0 - Adapt WSGI (Python 2.X) 2.0 to Python 3.X. Use > definition #4 (or more likely a variation on it). For that I would rather go like this: WSGI 1.0 stays the same as PEP 0333 currently is WSGI 1.1 becomes what Ian and I added to PEP 0333 WSGI 2.0 becomes a modified version of PEP WSGI 3.0 like XXX but drops start_response > One reason for still keeping bytes everywhere in Python 2.X is that is > because how it is and if unicode introduced then possibly would just > be ignored by people anyway. If WSGI 2.0 based on the list above introduces unicode to both Python 2.x and Python 3.x not much would change for the user. Frameworks are already using unicode everywhere already, if the decoding step happens in the webserver they just would have to make their own decoding a NOOP if they detect version (2, 0). > Second reason is whereby Ian is promoting PEP 0383 as way of resolving > transcoding issues If we want to be WSGI still Python 2.x compliant for all version (which I hope we do), that is out of the question. Also latin1 is fine because it's actually what HTTP speaks and does not drop any information. For URIs we do what browsers do already which also does not lose any information. Don't see what 0383 gives us we can't have with what you and Robert are already doing. > So, perhaps we can step back for a minute and ask those couple of > major questions. To state them again, they were:
