

PEP 3333 Accepted: WSGI standard for Python 3.x - enduser
http://mail.python.org/pipermail/web-sig/2011-January/004979.html

======
jtchang
The PEP process has always amazed me as one of the better processes that the
Python community "owns". Certainly not perfect but I feel the focus on
communication is really key.

Does Ruby have something similar when it comes to enhancements?

~~~
jpcx01
Yep, Ruby has どのような...我々は日本だ。我々は性交を与えていない

~~~
kbd
lol -
[http://translate.google.com/#ja|en|%E3%81%A9%E3%81%AE%E3%82%...](http://translate.google.com/#ja|en|%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AA...%E6%88%91%E3%80%85%E3%81%AF%E6%97%A5%E6%9C%AC%E3%81%A0%E3%80%82%E6%88%91%E3%80%85%E3%81%AF%E6%80%A7%E4%BA%A4%E3%82%92%E4%B8%8E%E3%81%88%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84)

~~~
T-R
Maybe something more like:

えっ？全然興味ないんだけど。日本にいるんじゃん？

Sorry to kill the joke, but if Google translates it into grammatically correct
English, the source was nothing resembling Japanese.

------
rfugger
<http://www.python.org/dev/peps/pep-3333/>

------
Wilduck
This has been a long time coming. Not being able to use Python3.x for web
development was a large barrier for me switching completely. Now Python3.x
just needs to be the default for more linux distros.

~~~
tapiwa
I agree. Python 3 will not see significant uptake till it is the default on
most distros.

It is the usual chicken and egg problem. Distros won't upgrade if there is no
reason to. In fact, many are reluctant to upgrade to 3.0 since it breaks a few
mini-apps developed in 2.x (as happened to me on ArchBang Linux a few weeks
ago).

You need a killer app to force through the migration. Viz Rails and the number
of hosts who now have Ruby hosting (if only in name) even on their cheapest
hosting packages.

~~~
dagw
_You need a killer app_

The larger problem is that all the existing killer apps need porting over
first. Python has a large ecosystem of killer apps (or rather libraries)
already, so no matter how killer your new app is, it probably won't outkill
the sum total of all existing killer apps.

------
kmfrk
A summary in layman's words?

More specifically about the implications.

~~~
enduser
WSGI defines the interface between web services written in Python and HTTP.
mod_wsgi is the Apache implementation. FLUP is frequently used to gateway WSGI
to FastCGI (for use with nginx). There are others.

Until now, people writing WSGI applications (mostly framework authors) have
been held back by lack of standardization. WSGI adapters such as mod_wsgi have
been tracking PEP 3333 for some time, but web application/framework authors
have been reluctant to move forward without standardization.

Jacob Kaplan-Moss wrote:

"The lack of a WSGI answer on Py3 is the main thing that's keeping me,
personally, from feeling excited about the platform. Once that's done I can
feel comfortable coding to it -- and browbeating those who don't support it."

See [http://mail.python.org/pipermail/web-
sig/2011-January/004902...](http://mail.python.org/pipermail/web-
sig/2011-January/004902.html) for more of his point of view on why PEP 3333 is
important.

So: standardization has arrived. I would say that lack of WSGI for Python 3.x
was the primary factor holding back widespread standardization on Python 3.x.
It will take some time for adoption to occur nonetheless--there are other
factors. It is extra work to maintain a project with Python 3.x and 2.x
compatibility. Also the Python 3.x standard library needs more users to smooth
out the lumps.

Nonetheless, this is a big deal and should be celebrated :-)

------
bl4k
Any other Python devs still going to stick with 2.x despite this? I know I
will be, for the foreseeable future.

This was a big step for 3.0 adoption, but there is still a long way to go. It
reminds me of PHP4 v PHP5, but with far less clear benefits (and far less
support).

~~~
viraptor
I'm sorry - what is this 3.0 you speak of? Debian stable still runs on 2.5.
Surprisingly, almost every module I need from pypi works without problems
(sometimes just requires select26 to get the proper epoll). Most changes that
would be otherwise needed are really trivial (from __future__ import ...).

~~~
mambodog
There are some improvements to Unicode handling 3.0 that clean things up a
bit, which I'd appreciate after fighting with it recently.

