[Python-Dev] Re: [Stackless] comments on PEP 219

[Gordon McMillan]

[Jeremy]
> 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 
Stackless.
 
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 
<wink>].
 
> 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. 
>   (It
>     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 
worked).

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...]


- Gordon