python concurrency proposal

[Corey Coughlin]

<snip>
> Yes.  Parallelism certainly deserves attention, and I believe
> "amateurs" are likely to help in the breakthroughs to come.  I
> further suspect, though, that they'll be amateurs who benefit
> from knowledge of existing research into the range of documented
> concurrency concepts, including CSPs, tasks, guarded methods, 
> microthreads, weightless threads, chords, co-routines, and so on.

Yes, there are lots of different concepts, even in python, there's pympi 
(as was mentioned), the standard python thread library, the subprocess 
library, generators, microthreads and stackless, not to mention 
Candygram, PyLinda, ATOM, Kamaelia (get to that in a minute), and other 
things you can search for on the web.  My motivation here is just to see 
if I can find some lowest common denominator, to try to simplify this 
stuff to the point where the whole concept is a little easier to use, 
and the plumbing can be hidden away somewhere so "amateurs" don't have 
to worry about it (too much) if they don't want to.
	Now to be more specific, there does seem to be a lot of work with 
generators to set up concurrency, and that's fine, but it does seem like 
it takes a bunch of scaffolding and a different way of looking at 
things, and it's not really obvious to me how it can scale up on 
multiple processor systems with the GIL still in place.  Now I'm not 
sure that this will be the answer to all the problems, but breaking the 
global address space and making it easy to break up jobs into small 
communicating chunks seems like it would be a good way to go.  Or maybe 
I'm missing something?  Is there anything you'd care to elaborate on?