[Stackless] comments on PEP 219
gmcm at hypernet.com
Tue Mar 13 18:17:39 CET 2001
> Here are some comments on Gordon's new draft of PEP 219 and the
> stackless dev day discussion at Spam 9.
> I left the dev day discussion with the following takehome
> message: There is a tension between Stackless Python on the one
> hand and making Python easy to embed in and extend with C
> programs on the other hand. The PEP describes this as the major
> difficulty with C Python. I won't repeat the discussion of the
> problem there.
Almost all of the discussion about interpreter recursions is
about completeness, *not* about usability. If you were to
examine all the Stackless using apps out there, I think you
would find that they rely on a stackless version of only one
builtin - apply().
I can think of 2 practical situations in which it would be *nice*
to be rid of the recursion:
- magic methods (__init__, __getitem__ and __getattr__ in
particular). But magic methods are a convenience. There's
absolutely nothing there that can't be done another way.
- a GUI. Again, no big deal, because GUIs impose all kinds of
restrictions to begin with. If you use a GUI with threads, you
almost always have to dedicate one thread (usually the main
one) to the GUI and be careful that the other threads don't
touch the GUI directly. It's basically the same issue with
As for the rest of the possible situations, demand is
nonexistant. In an ideal world, we'd never have to answer the
question "how come it didn't work?". But put on you
application programmers hat for a moment and see if you can
think of a legitimate reason for, eg, one of the objects in an
__add__ wanting to make use of a pre-existing coroutine
inside the __add__ call. [Yeah, Tm can come up with a
reason, but I did say "legitimate".]
> I would like to seem a somewhat more detailed discussion of this
> in the PEP. I think it's an important issue to work out before
> making a decision about a stack-light patch.
I'm not sure why you say that. The one comparable situation
in normal Python is crossing threads in callbacks. With the
exception of a couple of complete madmen (doing COM
support), everyone else learns to avoid the situation. [Mark
doesn't even claim to know *how* he solved the problem
> The problem of nested interpreters and the C API seems to come up
> in several ways. These are all touched on in the PEP, but not in
> much detail. This message is mostly a request for more detail
> - Stackless disallows transfer out of a nested interpreter.
> has, too; anything else would be insane.) Therefore, the
> specification for microthreads &c. will be complicated by a
> listing of the places where control transfers are not
> possible. The PEP says this is not ideal, but not crippling.
> I'd like to see an actual spec for where it's not allowed in
> pure Python. It may not be crippling, but it may be a
> tremendous nuisance in practice; e.g. remember that __init__
> calls create a critical section.
The one instance I can find on the Stackless list (of
attempting to use a continuation across interpreter
invocations) was a call the uthread.wait() in __init__. Arguably
a (minor) nuisance, arguably bad coding practice (even if it
I encountered it when trying to make a generator work with a
for loop. So you end up using a while loop <shrug>.
It's disallowed where ever it's not accomodated. Listing those
cases is probably not terribly helpful; I bet even Guido is
sometimes surprised at what actually happens under the
covers. The message "attempt to run a locked frame" is not
very meaningful to the Stackless newbie, however.
[Christian answered the others...]
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless