[Web-SIG] Python 3 / PEP 3333 (was: PEP 444 / WSGI 2 Async)

[Jacob Kaplan-Moss]

On Fri, Jan 7, 2011 at 1:23 AM, Alice Bevan–McGregor
<alice at gothcandy.com> wrote:
> Other than mod_wsgi, are there any PEP 3333-compliant (or near-compliant)
> components in the wild?  Enough to bring a framework to life in Python 3?
>  What I see is the chicken-and-egg problem endemic with Python 3: developers
> wait on upstream to port before they do, and upstream developers are either
> waiting themselves or don't see the demand to port.

I don't see that problem any more. I have at least three WSGI servers
I could test against: modwsgi, CherryPy, and Django's half-assed
built-in server. I guess I could add wsgiref as a 4th, but only sorta.
And looks like Benoit's geting Gunicorn up to snuff.

What happens now goes something like this:

1. Get excited to port Django to Python 3.
2. Hack for a while.
3. Get something working under runserver - woo!
4. Hm, it fails under modwsgi.
5. OK, problem fixed.
6. Wait, no, now it doesn't work under runserver.
7. Or CherryPy. Dammit.
8. Lose interest for another 6 months.

At this point, there's a bug somewhere. It's *probably* in my code --
like I said earlier, I only barely grok WSGI -- but without a spec to
refer to I'm pretty much hosed. See, Django on Py 2 jumps through a
whole bunch of hoops to gloss over the string/unicode distinction and
over the question of encoding, and that's stuff's pretty fiddley. The
"right" way to handle that on Python 3 depends entirely on the issues
hammered out in PEP 3333 -- particularly the byte/str decisions. I'm
starting to assume that PEP 3333 is going to get accepted in a form
fundamentally the same as it appears right now, but if I'm wrong I get
to do this stuff all over again. Nothing's more of an
enthusiasm-killer than knowing I might have to start all over again
later.

I really want a definitive answer. If the spec says it's my fault, I
want people to yell at me loudly until Django is compliant. If the
spec says it's not my fault, I want to be able to be an asshole [1]
until all the app containers are compliant.

[1] That's a technical term; see
http://diveintomark.org/archives/2004/08/16/specs.

>> Can we please, please, PLEASE, pause discussion of PEP 444 until PEP 3333
>> is finalized?
>
> This is something I've seen fairly often around PEP 444 threads; instead of
> reviving (or starting a new) PEP 3333 thread, a complaint is levied against
> PEP 444 discussion itself.  That doesn't help.  ;)

Unfortunately, I really don't know any other way of helping than being
a pain in the ass. I don't understand the issues well enough to
contribute technically, so I've decided I'm going to continue to
complain loudly. Hopefully you'll get sick of me and give me a spec so
I'll shut the hell up!

I do feel crappy asking you to put 444 on hold. I understand that the
SIG should be perfectly capable of working on more than one thing at
once. However, to my eyes it seems like it keeps getting derailed. I
understand this, too: clearly WSGI isn't perfect, and when you run up
against some of those issues it's a *lot* more fun to ignore 'em just
for a bit longer and work on something more exciting.

I really do appreciate the enthusiasm for PEP 444. I share it: it
seems a lot easier to implement, and it'll certainly make some of the
things Django's doing a lot easier. I just would really like to see
that enthusiasm and energy turned full blast on PEP 3333 until it's
done.

Jacob

(Luckily for you, I'm going on vacation tomorrow, so you won't have to
deal with me me complaining for at least a week!)