[Python-Dev] Re: Python 2.0 and Stackless

[Christian Tismer]

Moshe Zadka wrote:
> 
> On Sat, 5 Aug 2000, Eric S. Raymond wrote:
> 
> > I must say I agree.  Something pretty similar to Stackless Python is
> > going to have to happen anyway for the language to make its next major
> > advance in capability -- generators, co-routining, and continuations.
> >
> > I also agree that this is a more important debate, and a harder set of
> > decisions, than the PEPs.  Which means we should start paying attention
> > to it *now*.
> 
> I tend to disagree. For a while now I'm keeping an eye on the guile
> interpreter development (a very cool project, but unfortunately limping
> along. It probably will be the .NET of free software, though). In guile,
> they were able to implement continuations *without* what we call
> stacklessness. Sure, it might look inefficient, but for most applications
> (like co-routines) it's actually quite all right.

Despite the fact that I consider the Guile implementation a pile
of junk code that I would never touch like I did with Python*),
you are probably right. Stackless goes a bit too far in a sense,
that it implies abilities for other implementations which are
hard to achieve.

There are in fact other ways to implement coroutines and uthreads.
Stackless happens to achieve all of that and a lot more, and to
be very efficient. Therefore it would be a waste to go back to
a restricted implementation since it exists already. If stackless
didn't go so far, it would probably have been successfully
integrated, already. I wanted it all and luckily got it all.

On the other hand, there is no need to enforce every Python
implementation to do the full continuation support. In CPython,
continuationmodule.c can be used for such purposes, and it can
be used as a basement for coroutine and generator implementations.
Using Guile's way to implement these would be a possible path
for JPython.
The point is to use only parts of the possibilities and don't
enforce everything for every environment. There is just no point
in shrinking the current implementation down; not even a subset
would be helpful in JPython.

> What all that goes to
> say is that we should treat stackles exactly like it is -- an
> implementation detail. Now, that's not putting down Christian's work -- on
> the contrary, I think the Python implementation is very important. But
> that alone should indicate there's no need for a PEP. I, for one, am for
> it, because I happen to think it's a much better implementation. If it
> also has the effect of making continuationsmodule.c easier to write, well,
> that's not an issue in this discussion as far as I'm concerned.

A possible proposal could be this:

- incorporate Stackless into CPython, but don't demand it
  for every implementation
- implement coroutines and others with Stackless for CPython
  try alternative implementations for JPython if there are users
- do *not* make continuations a standard language feature until
  there is a portable way to get it everywhere

Still, I can't see the point with Java. There are enough
C extension which are not available for JPython, but it is
allowed to use them. Same with the continuationmodule, why
does it need to exist for Java, in order to allow it for
CPython?
This is like not implementing new browser features until
they can be implemented on my WAP handy. Sonsense.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com

*) sorry, feel free to disagree, but this was my impression when
   I read the whole code half a year ago.
   This is exactly what I not want :-)