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.
Good to hear (thanks)! Alas, multiprocessing will always be slagged by the serialization and deserialization of objects. Note, I'm the maintainer, so I'm not trolling :)
Sheesh, all these years you think people who write core modules are robots and then one day one comes up and replies to you on a message board! :) What you say is true, but in any case, my congratulations on a very pretty API.
Incidentally, another story by Karel Čapek - http://en.wikipedia.org/wiki/The_Absolute_at_Large -
features a "reactor that can annihilate matter to produce cheap and abundant energy [and] as a by-product, the absolute. The absolute is a spiritual essence".
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.
When talking about an interpreter; I find those terms completely acceptable. So long as the language itself continues to work, and I can still use C extensions.
The C extension are one reason why some features are so hard to implement. E.g. reference counting will always be with us, because the current interface to the C extensions rely on it. And you had to change all of them, if you wanted to get rid of it.
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 could 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.
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.
Cooperative userspace threads work very well for the kinds of applications you write in Python.
What is with developers naming their projects newsomething?
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 newwhatever projects.
It's such a lazy, uninformative, short-sighted way of naming your work.
Someone voted me down; I suppose I'm am being a little too aggressive about it but I do think it's a stupid way to name a project. :-)
Most of these projects represent a lot of work and a huge revolutionary leap over the "old" projects. It seems like that much work deserves a more fitting name.
"There are only two hard things in Computer Science: cache invalidation and naming things." -Phil Karlton
No, it would not get into 3.2, and it doesn't offer speed improvements at this time. It's a great experiment right now. It's probably a year+ off from ever seeing core, if ever.
As a sidenote, the John Nagle there is the same one in Nagle's algorithm: http://en.wikipedia.org/wiki/Nagle%27s_algorithm