I know it's not the same thing, but I quite liked multiprocessing. Although it's severely limited in terms of passing objects around and there is always the overhead of spawning new processes.<p>As a sidenote, the John Nagle there is the same one in Nagle's algorithm:
<a href="http://en.wikipedia.org/wiki/Nagle%27s_algorithm" rel="nofollow">http://en.wikipedia.org/wiki/Nagle%27s_algorithm</a>
There are dozens of things that would have to be broken to make this work, for instance sys.set_trace. Either tracing is broken, or tracing is rewritten with a new threading strategy (that's not this strategy) or you're back to GIL-land.
Very, very interesting. I'm going to have to suck it up and pull it from sourceforge - I'll be very interested to see how they implemented the message passing and "safe object" stuff. With time this <i>could</i> change things quite a bit for python.
The path from a pure python user-level threading library to eliminating the GIL in CPython is longer than the subject implies.<p>Something to keep in mind with Python/Perl/Ruby anyway: Making your app run on 2 cores makes it 2x faster. Implenting your algorithm in Haskell instead makes it 50x faster.<p>Cooperative userspace threads work very well for the kinds of applications you write in Python.
What is with developers naming their projects <i>new</i>something?<p>Django had newforms, Java had nio and Guido van Rossum just posted about the multiple inheritence method resolution order (MRO) which had a python 2.2 new-style and python 2.3 new-style. I could probably come up with a huge list of <i>new</i>whatever projects.<p>It's such a lazy, uninformative, short-sighted way of naming your work.
Looks very cool.<p>Of course, I am already fantasizing about it being merged to the main branch. Assuming it will work well, is this something that can get into 3.2?<p>I saw this release schedule for 3.2:
<a href="http://www.python.org/dev/peps/pep-0392/" rel="nofollow">http://www.python.org/dev/peps/pep-0392/</a><p>I see that 3.2 alpha 1 is due today.