[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Occam-Tau anyone???
On 5 October 2012 16:10, Larry Dickson <tjoccam@xxxxxxxxxxx> wrote:
> Hi Jeremy,
>
> There is, or was, a thing called "Stackless Python" which started out as
> something CSP-like in the Python universe. By the time I looked at it
> (around 2009?) it had drifted away from this and was certainly no longer
> stackless.
Stackless Python still exists.
The word "stackless" derives from the fact that the origin python
runtime - normally referred to as CPython - creates 2 call stacks when
you call a python function. One is a underlying C stack, and the other
was a python stack frame. The former resides properly on the stack,
and the other on the heap. As I understand it. stackless eradicates
the c-stack and manipulates the python stack frame directly like any
other python object. It does this by switching in/out the appropriate
stack at any given point in time.
This was originally implemented with the idea of continuations in
mind, and was changed for the idea of Tasklets instead. This allows
multiple things to be done inside a single thread and is particularly
useful in turning asynchronous server code back the rightway in.
Tasklets can communicate over channels, and this is still a core idea
of stackless.
While stackless itself has never been merged into mainline CPython,
two things happened:
* The originator of stackless joined the pypy team, and many of the
interesting ideas in Python - like stackless ideas - are continuing
there.
* The "switching of stack frames" thing got ported to mainline
CPython as a c-extension - and was called greenlets.
Greenlets are used in a number of python libraries, and especially
things like gevent, as used in large scale systems via things like
tornado.
Stackless itself is notably used in systems like Eve online which is a
rather large parallel system.
The key point here is integration - stackless didn't integrate, so
people found a way of taking what was useful from it and integrating
it with their systems.
If Occam is to be relevant in the future, the community around it
itself "how can we be useful". Not "how can we force the world into
our programming paradigm".
Otherwise it will remain an academic curiosity that randomly tells
other people they're doing it wrong. People don't pick up a tool
because of purity, they pick up a tool primarily out of economic need
and benefit - and there "good enough" is often preferred over
"provably correct".
Asking the Occam community to embrace "good enough" over "provably
correct", may be asking too much though - based on reading the threads
in the past few days.
Michael.