Python 2.0 and Stackless

[Alexander Williams]

Christian Tismer <tismer at appliedbiometrics.com> writes:

> Toby Dickenson wrote:
> > Consider this "naive" function
> > 
> > def m(y):
> >    x()
> >    try:
> >       y()
> >    finally:
> >       z()
> > 
> > Today I can be sure that a call to z is always preceeded by a single
> > call to x. Stacklessness makes that assumption false.

Moreover, even this isn't guaranteed.  y() can have a call to x()
inside it that is executed (and has side-effects!) before an exception
is raised and z()( is called.

Let's assume, however, you meant that you are guaranteed at least ONE
call to x() before z() is executed.  If we compile Stackless into your
Python interpreter, and then create this same function ... you still
have this guarantee.  There's no "call-with-cc" bit in here or other
juggling that might affect flow control.  The only places they might
be placed are down in the guts of x() or y(), and in the latter case
it doesn't invalidate your expectation and in the former, well, how is
that different from calling z() /within/ x()?  You're still not
guaranteed a completed x() call before an invocation of z().

Alright, so if we limit it to *just* the context of this single stack
frame/function, and we compile in Stackless ... nothing changes.  Oh,
sure, you can make the guts of x(), y(), or z() as complex as you like
with mutually calling continuations ... but in the context of just
m(), it doesn't matter much, or at least, no moreso than it did
before.

-- 
Alexander Williams (thantos at gw.total-web.net)           | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins