[Python-Dev] 'stackless' python?

[Guido van Rossum]

> I know this is disgusting, but could setjmp/longjmp 'automagically'
> force a 'recursive call' to jump back into the top-level loop?  This
> would put some serious restraint on what C called from Python could
> do...

Forget about it.  setjmp/longjmp are invitations to problems.  I also
assume that they would interfere badly with C++.

> I think just about any Scheme implementation has to solve this same
> problem... I'll dig through my collection of them for ideas.

Anything that assumes knowledge about how the C compiler and/or the
CPU and OS lay out the stack is a no-no, because it means that the
first thing one has to do for a port to a new architecture is figure
out how the stack is laid out.  Another thread in this list is porting 
Python to microplatforms like PalmOS.  Typically the scheme Hackers
are not afraid to delve deep into the machine, but I refuse to do that
-- I think it's too risky.

>   > In general, I still think it's a cool idea, but I also still think
>   > that continuations are too complicated for most programmers.  (This
>   > comes from the realization that they are too complicated for me!)
>   > Corollary: even if we had continuations, I'm not sure if this would
>   > take away the resistance against asyncore/asynchat.  Of course I could 
>   > be wrong.
> 
> Theoretically, you could have a bit of code that looked just like
> 'normal' imperative code, that would actually be entering and exiting
> the context for non-blocking i/o.  If it were done right, the same
> exact code might even run under 'normal' threads.

Yes -- I remember in 92 or 93 I worked out a way to emulat coroutines
with regular threads.  (I think in cooperation with Steve Majewski.)

> Recently I've written an async server that needed to talk to several
> other RPC servers, and a mysql server.  Pseudo-example, with
> possibly-async calls in UPPERCASE:
> 
>   auth, archive = db.FETCH_USER_INFO (user)
>   if verify_login(user,auth):
>     rpc_server = self.archive_servers[archive]
>     group_info = rpc_server.FETCH_GROUP_INFO (group)
>     if valid (group_info):
>       return rpc_server.FETCH_MESSAGE (message_number)
>     else:
>       ...
>    else:
>      ...
> 
> This code in CPS is a horrible, complicated mess, it takes something
> like 8 callback methods, variables and exceptions have to be passed
> around in 'continuation' objects.  It's hairy because there are three
> levels of callback state.  Ugh.

Agreed.

> If Python had closures, then it would be a *little* easier, but would
> still make the average Pythoneer swoon.  Closures would let you put
> the above logic all in one method, but the code would still be
> 'inside-out'.

I forget how this worked :-(

>   > Different suggestion: it would be cool to work on completely
>   > separating out the VM from the rest of Python, through some kind of
>   > C-level API specification.
> 
> I think this is a great idea.  I've been staring at python bytecodes a
> bit lately thinking about how to do something like this, for some
> subset of Python.
> 
> [...]
> 
> Ok, we've all seen the 'stick'.  I guess I should give an example of
> the 'carrot': I think that a web server built on such a Python could
> have the performance/scalability of thttpd, with the
> ease-of-programming of Roxen.  As far as I know, there's nothing like
> it out there.  Medusa would be put out to pasture. 8^)

I'm afraid I haven't kept up -- what are Roxen and thttpd?  What do
they do that Apache doesn't?

--Guido van Rossum (home page: http://www.python.org/~guido/)