Re: [Web-SIG] Is PEP 3333 the final solution for WSGI on Python 3?
Hi, On 10/23/10 7:43 PM, P.J. Eby wrote: I don't think it's an either-or case. PEP just means that there's a clear path to port WSGI 1 apps. If somebody wants to champion a WSGI 1.1, a 2.0, and whatever else, that's great! Oh, I was not denying that. The original post on reddit to which I commented was called Is PEP the final solution for WSGI on Python 3 :) I'm really trying to step *down* from involvement in this; the only reason I stepped up to do this now is because of the pending 3.2 release and the open question(s) over stdlib APIs that have to stabilize in this release. I think the main problem is that we are all incredible happy with Python 2 currently and Python 3 is not very convincing at the moment. Unleaden Swallow also did not exactly deliver to it's promises lately, but PyPy seems to be doing quite well lately, and due to it's nature it would be unrealistic to assume it switches to Python 3 anytime soon. (It's one of the largest Python 2 codebases) I have to admit that my interest in Python 3 is not very high and I am most likely not the most reliable person when it comes to driving PEP 444 :) 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] Is PEP 3333 the final solution for WSGI on Python 3?
On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote: Am 24.10.2010 16:40, schrieb Chris McDonough: On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote: I have to admit that my interest in Python 3 is not very high and I am most likely not the most reliable person when it comes to driving PEP 444 :) We should probably withdraw the PEP, then (unless someone else wants to step up and champion it), because neither am I. Don't give it up yet -- Deferring is probably the better option. TBH, unless someone has immediate interest in championing it, I'd rather just withdraw it and let someone else resubmit it (or something like it) later if they want. It's just going to cause confusion if it's left in a zombie state without a champion. - C ___ 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] Is PEP 3333 the final solution for WSGI on Python 3?
Am 24.10.2010 17:58, schrieb Chris McDonough: On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote: Am 24.10.2010 16:40, schrieb Chris McDonough: On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote: I have to admit that my interest in Python 3 is not very high and I am most likely not the most reliable person when it comes to driving PEP 444 :) We should probably withdraw the PEP, then (unless someone else wants to step up and champion it), because neither am I. Don't give it up yet -- Deferring is probably the better option. TBH, unless someone has immediate interest in championing it, I'd rather just withdraw it and let someone else resubmit it (or something like it) later if they want. It's just going to cause confusion if it's left in a zombie state without a champion. Ah, but Deferred is an official state, and describes quite clearly what state it is in -- not obsolete, but without an active champion. 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] Is PEP 3333 the final solution for WSGI on Python 3?
On Sun, Oct 24, 2010 at 10:17 AM, Georg Brandl g.bra...@gmx.net wrote: Am 24.10.2010 17:58, schrieb Chris McDonough: On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote: Am 24.10.2010 16:40, schrieb Chris McDonough: On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote: I have to admit that my interest in Python 3 is not very high and I am most likely not the most reliable person when it comes to driving PEP 444 :) We should probably withdraw the PEP, then (unless someone else wants to step up and champion it), because neither am I. Don't give it up yet -- Deferring is probably the better option. TBH, unless someone has immediate interest in championing it, I'd rather just withdraw it and let someone else resubmit it (or something like it) later if they want. It's just going to cause confusion if it's left in a zombie state without a champion. Ah, but Deferred is an official state, and describes quite clearly what state it is in -- not obsolete, but without an active champion. And here I thought for a second you were changing the topic to Twisted. :-) -- --Guido van Rossum (python.org/~guido) ___ 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] Is PEP 3333 the final solution for WSGI on Python 3?
Hi, On 10/22/10 2:35 AM, Graham Dumpleton wrote: has said: Hopefully not. WSGI could do better and there is a proposal for that (444). Just to give this some more context: I think WSGI (even in Python 2) is faulty and we have the possibility now to fix it. Nobody in the web community is really eager to use Python 3 currently as far as I can see, so we have some extra time where we can actually introduce some value in to web development on Python 3. An improved WSGI specification could be a key to that. If PEP is what we end up with, that is fine with me as well. 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] Is PEP 3333 the final solution for WSGI on Python 3?
On Sat, Oct 23, 2010 at 12:43 PM, P.J. Eby p...@telecommunity.com wrote: I don't think it's an either-or case. PEP just means that there's a clear path to port WSGI 1 apps. If somebody wants to champion a WSGI 1.1, a 2.0, and whatever else, that's great! I agree, I think PEP is fine in its scope, it just makes WSGI 1 clearer and gives a practical and usable path for Python 3 migration. A newer protocol, whether that's 444 or something else, should then remain a separate effort, and there's no urgent need to rush that now just so we can get Python 3 support. Also we should be keeping closer tabs on how the HTTPbis efforts at the IETF are doing, as a newer replacement protocol should definitely be coherent with that. In the mean time, I'd like to see the draft 444 updated soon to better reflect it's base on rather than 333. -- Deron Meranda http://deron.meranda.us/ ___ 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] Is PEP 3333 the final solution for WSGI on Python 3?
On Thu, Oct 21, 2010 at 6:35 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: No other developers of actual web frameworks has commented at all on PEP from what I can see. I wrote a bunch about WSGI/Py3 on python-dev: http://mail.python.org/pipermail/python-dev/2010-September/103674.html http://mail.python.org/pipermail/python-dev/2010-September/103717.html http://mail.python.org/pipermail/python-dev/2010-September/103744.html http://mail.python.org/pipermail/python-dev/2010-September/103887.html My feelings haven't changed: deploying Python 2 is awesome. Deploying Python 3 is impossible. To quote at length from myself: Deploying web apps under Python 2 right now is actually pretty awesome. There's a clear leader in mod_wsgi that's fast, stable, easy to use, and under active development. There's a few great lightweight pure-Python servers, some new-hotness (Gunicorn) and some tried-and-true (CherryPy). There's a fast-as-hell bleeding-edge option (nginx + uwsgi). And those are just the ones I've successfully put into production -- there're still *more* options if one of those won't cut it. The key here is that switching between all of these deployment situations is *incredibly* easy. [...] Python 3 offers me none of this. I don't have a wide variety of tools to choose from. Worse, I don't even have a guarantee of interoperability between the tools that *do* exist. The reason I'm not chiming on on vs 444 is that I DON'T CARE. Just give me something that works on Python 3, dammit. I can't even begin to think about moving to Python 3 until I've got a solid standard with multiple implementations. It seems to me that PEP could land faster than PEP 444, but if that's not true, again, I don't care. I just want a deployment answer for Python 3. I'm sorry if I sound petulant here, but I'm really quite frustrated. I want to be moving to Python 3 a couple of years ago, and I just don't understand the issues and problems in WSGI and web servers to be able to help out. If I was smart enough, I'd help. Instead, I'm trying to use the bully pulpit any way I can. Please, people, move this damn thing forward. Jacob ___ 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] Is PEP 3333 the final solution for WSGI on Python 3?
For what it's worth, I'm happy with the changes made to WSGI 1 that produced PEP . I'm unlikely to champion PEP 444 going forward. It has already served its primary duty to me personally (which was to catalyze the formalization of some specification that is Python 3 inclusive). However, Armin may feel differently about it, so this doesn't constitute a withdrawal of PEP 444. I'm instead just signaling my own personal attitude: don't really care as much now that there's something out there. On Fri, 2010-10-22 at 10:35 +1100, Graham Dumpleton wrote: Any one care to comment on my blog post? http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html As far as web framework developers commenting, Armin at: http://www.reddit.com/r/Python/comments/du7bf/is_pep__the_final_solution_for_wsgi_on_python/ has said: Hopefully not. WSGI could do better and there is a proposal for that (444). So, looks he is very cool on the idea. No other developers of actual web frameworks has commented at all on PEP from what I can see. 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/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] Is PEP 3333 the final solution for WSGI on Python 3?
I did a solution based on the old PEP and works very well to me, i don't know if could be used by others if any are interested i can send it. El , Graham Dumpleton graham.dumple...@gmail.com escribió: Any one care to comment on my blog post? http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html As far as web framework developers commenting, Armin at: http://www.reddit.com/r/Python/comments/du7bf/is_pep__the_final_solution_for_wsgi_on_python/ has said: Hopefully not. WSGI could do better and there is a proposal for that (444). So, looks he is very cool on the idea. No other developers of actual web frameworks has commented at all on PEP from what I can see. 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/hidura%40gmail.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] Is PEP 3333 the final solution for WSGI on Python 3?
At 10:35 AM 10/22/2010 +1100, Graham Dumpleton wrote: Any one care to comment on my blog post? http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html As far as web framework developers commenting, Armin at: http://www.reddit.com/r/Python/comments/du7bf/is_pep__the_final_solution_for_wsgi_on_python/ has said: Hopefully not. WSGI could do better and there is a proposal for that (444). So, looks he is very cool on the idea. No other developers of actual web frameworks has commented at all on PEP from what I can see. Graham Just out of curiosity, Graham, isn't PEP basically only a slight modification to what you yourself proposed and implemented in mod_wsgi for Python 3? My guess is that there's been no comment because there's really not much to say about it. The most controversial thing about it was Python-Dev's objection to modifying PEP 333 in place -- and that's the *only* reason why it's a new PEP at all. (Indeed, I originally just made the discussed amendments to PEP 333, and specifically wanted to avoid having a new PEP number in order to create unnecessary additional discussion or questions.) ___ 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] Is PEP 3333 the final solution for WSGI on Python 3?
On 22 October 2010 11:16, P.J. Eby p...@telecommunity.com wrote: At 10:35 AM 10/22/2010 +1100, Graham Dumpleton wrote: Any one care to comment on my blog post? http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html As far as web framework developers commenting, Armin at: http://www.reddit.com/r/Python/comments/du7bf/is_pep__the_final_solution_for_wsgi_on_python/ has said: Hopefully not. WSGI could do better and there is a proposal for that (444). So, looks he is very cool on the idea. No other developers of actual web frameworks has commented at all on PEP from what I can see. Graham Just out of curiosity, Graham, isn't PEP basically only a slight modification to what you yourself proposed and implemented in mod_wsgi for Python 3? Correct, it is a bit more strict and changes wsgi.version back to 1.0. So, except for wsgi.version, Apache/mod_wsgi already technically conforms to it. I will be stepping a bit outside of the specification and having non CGI variables in environment from Apache configuration be treated as UTF-8 +surrogateescape however, with means to override the encoding. This though is going to be necessary because of capabilities of Apache and not an issue with WSGI specification. My guess is that there's been no comment because there's really not much to say about it. The most controversial thing about it was Python-Dev's objection to modifying PEP 333 in place -- and that's the *only* reason why it's a new PEP at all. I am not sure that it is that simple and that it is a done deal. Some people have been quite passionate about having bytes used in more places and the near silence from those people has me concerned that all is going to happen is that they will ignore PEP and another discussion will just erupt again later. It will be quite disappointing if Armin especially takes that stance and will not support PEP in Werkzeug, skip it and seek out an alternative. As I say in my blog post, ultimately it may not matter as PEP continues the WSGI name and so if they don't like it then what they come up with will have to be under a different name else it will be too confusing. At this point I can't see a future version based on PEP 444 being called WSGI 2.0, it is just going to be better to be clearly distinct in name after all that has gone on before. As such, Apache/mod_wsgi can be made to align with PEP for Python 3 and if anything else comes along later under a different name, then Apache/mod_wsgi will simply not implement it since it is specific to WSGI. If people want to somehow use Apache/mod_wsgi for it, they will have to use an adapter, if possible. Otherwise people will have to rely on other hosting mechanisms, be those other existing ones where author is prepared to support any new interface and not so fussy about naming inconsistencies or anything new that may come along. Thus I am just after some acknowledgement from involved parties that it is accepted that PEP is the way forward for WSGI for Python 3 and that it isn't just going to be ignored. Without that, as far as I am concerned we are still in limbo with only a little bit more mandate than before because of you having created the update as new PEP , yet with no one pledging to accept it and use it going forward for major web frameworks. FWIW, what is the normal process for getting a PEP accepted as being the way of doing things so people all agree? Note that I haven't been reading python-dev list, so maybe there was some sort of agreement already expressed there which means PEP already has some sort of mandate and people just have to accept it, don't know. 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
