Right. That PEP better explain how one writes C code that calls into Python without involving the C stack as well!
I believe the outstanding proposal is that attempting a task switch from within Python code that was called by an extension will fail with an exception.
But how do you define "called by an exception"? There are lots built-in data types that call back into Python, e.g. comparisons and hash for dict keys, list.sort, sets, etc...
Last time we looked there were so many exceptions of this type that enumerating them all was hopeless. That's a problem for a PEP.
But, if you mean, "how do you write a new piece of C that calls the interpreter, such that it can allow task switching to take place from the invoked interpreter?", then that's a different question, which should definitely be answered in the PEP.
That's what I meant, yes.
The problem I see is that *any* operation on a Python object potentially involves C calling Python, which seems to mean that the changes to the core interpreter would have to be quite widespread. But maybe the PEP authors have a more clever way to deal with that than anything I've thought of.
My way of dealing with this is to keep Stackless out of the core. Everybody happy.
--Guido van Rossum (home page: http://www.python.org/~guido/)