Stackless python and microthreads

[Mike C. Fletcher]

Michele Simionato wrote:

>"Mike C. Fletcher" <mcfletch at rogers.com> wrote in message news:<mailman.537.1084486879.25742.python-list at python.org>...
>  
>
>>Continuations (which are the coolest things since programming was 
>>invented) 
>>    
>>
...

>However, to pass from continuations to something useful takes a 
>LONG way. Continuations are a too low level concept. A high level language 
>should already provide the right high level tools. I mean, the language 
>designer should implement generators, exception systems, microthreads, etc. 
>not the application programmer. When you have the high level concepts written 
>down by others, you don't need continuations.
>  
>
Except we did ;) .  When we sat down to start working with 
micro-threads, they were (for our purposes) extremely heavy beasts when 
they were sleeping and scheduling themselves.  So, having a simple 
Python implementation built out of continuations, we were able to say 
"hey, we can fix that cheaply" and dedicate a few weeks of work to the 
project to improve the implementation.

Guido may be omniscient ;) , but I don't think he's achieved 
omnipotence.  He and the python-dev crowd can't, and *won't* implement 
many things that people writing frameworks *need* (and really, in many 
cases, they shouldn't be doing it anyway until the idea proves itself).  
Having a building block such as continuations exposed allows framework 
developers/meta-programmers the chance to experiment with new 
flow-control structures and to do that experimentation *in a high-level 
language* (does this sound familiar to all the PyPy peoples).

>So I guess now Stackless has microthreads built inside, and the application 
>programmer is not forced to write them on top of continations. 
>  
>
Sure, but it was never the app programmer that did it anyway, so let's 
leave them out of this.  Using Python does not automatically mean you 
are an applications programmer rather than a framework developer or 
meta-programmer (btw, nothing wrong with being an apps programmer, it's 
just a different type of work).  Python isn't *just* a scripting 
language either ;) .

>Speaking in general, generators and the current exception system are more 
>than enough for my typical needs in Python: which kind of applications do 
>you have in mind where you would like to have continuations? (a part from
>microthreads and things like changing the language introducing new
>control structures, etc, all stuff than should not be left to the
>application programmer, IMHO).
>  
>
Why make that kind of experimentation difficult just to erect a barrier 
between user and developer?  Python isn't a place to keep every powerful 
tool from the plebeian masses just because they might hurt themselves.  
Heck, if we're going to do that, what the heck are we exposing 
metaclasses for (and really, would the two of us be happy if they took 
away our metaclasses)?  There are framework developers/meta-programmers 
using Python who just aren't interested in working in C code any more.  
Giving them tools is *not* a bad thing.

Regarding applications; restartable exceptions, micro-threads, 
long-running-calculation restarts, migrating running code across 
machines, and creating new methods of parsing all seem like experiments 
that would benefit from having continuations available to ease 
implementation.  Any of those is a thing that an app programmer might 
want/need, and be willing to have a meta-programmer create for them... 
why force that work into C code needlessly?

However, continuations are dead, and though I may mourn them, I'm not 
interested in trying to resurrect them.  At the moment my company's 
current contracts would only be interested in are micro-threads; and 
even there, we aren't really interested enough to switch from our 
already-built frameworks; just too much inertia.  Too bad, because a 
micro-threaded networking environment is the closest thing I've ever 
seen to the promised land for networking... garn I miss working on that.

Peace all,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/