Python 3 / PEP 3333 (was: PEP 444 / WSGI 2 Async)

On 2011-01-06 21:35:24 -0800, Jacob Kaplan-Moss said:
> And I'm feeling incredibly disheartened.

As the author of my own small WSGI framework (with world-wide, though 
still limited use) I have the luxury of being able to embrace 
experimental technologies.  The lack of WSGI capability in Python 3 
thoroughly depressed me for the same reasons you describe.

Then I got fed up, tracked down something to tackle, and picked up PEP 
444 knowing full well that PEP 3333 existed and was nearer to 
completion.  PEP 3333 -should- be ratified ASAP in order for developers 
to begin to move forward.  PEP 444, despite the seeming high blood 
pressure on the Web-SIG list, is a long, long way off, and I recognize 
that.  Despite my boundless enthusiasm for debate, I certainly hope 
everyone else realizes this, too.  ;)

I wrote an experimental proof-of-concept HTTP/1.1 server against PEP 
444 (and continue to update it as my rewrite progresses) over the 
course of a week.  It just so happened to be stupidly performant under 
ideal conditions (see the webpy mailing list for a more real-world 
comparison against a CPython extension-based server), extremely simple 
code to maintain and experiment on, and will continue to be my/the 
"reference implementation" for PEP 444.

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.

Any standard needs early adopters / implementors in order to truly test 
the specification; without such, much of the discussion is pure 
thought-experiment and practical problems may arise after the standard 
is ratified, which is never good.  ;)

With the Marrow suite I'm attempting to brute-force the Python 3 
problem domain within the context of testing PEP 444 and providing 
(after ratification) a solid meta-framework foundation a la Paste.  
Yes, that means I'm re-inventing enough wheels for a 6-axel rig, but it 
also means (in theory) I should have a solid understanding of the 
strengths and weaknesses of the PEP.  (The WebOb equivalent is only 
partially complete as of this writing.)

> A few months ago, PJE posted PEP 3333. It looked good... and then 
> nothing happened. I tried  to prod things forward, and some more 
> discussion ensued... and now it looks like it's stalling again. Each 
> time, discussion of PEP 444 seems to derail discussion of PEP 3333.

I see the opposite in regards to recent traffic on the Web-SIG; PEP 444 
discussion has encouraged PEP 3333 discussion.  See the "Declaring PEP 
3333 accepted" thread (encouraged by Guido himself).

> At this rate, I really wonder if it'll be another two years before we 
> have a working WSGI for Python 3. I hope I'm being pessimistic. Prove 
> me wrong. Please.

I'll do what I can.  :)

> 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.  ;)

Truthfully, this month already surpasses the amount of activity 
(post-wise) of the last three months combined, and includes quite a 
number of posts about PEP 3333.  (PEP 3333 has had no significant 
discussion - again, by post count - since October.)

	- Alice.


_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org