"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Another possible solution is to use the Python multi-interpreter API, > wrapped via ctypes or Pyrex or some such, and using an interpreter per > plugin. Each interpreter has its own builtins, sys.modules and > sys.path, so each plugin sees the universe exactly as it wants to.
Each time I think about this, because there's a similar problem with inprocess COM servers on windows, I hear mostly from Mark Hammond that he has agreed with Guido that the multi-interpreter api is flawed (hope that's the correct term). Unfortuately the agreement seems to have been reached in private emails between those two only.
The principal issue I'm aware of with the multi-interpreter API is that extension modules that are loaded in multiple interpreters may still end up sharing their static data. I've looked at the implementation to a moderate depth, and I haven't seen any other major issues.
Well, actually, the new "safe threading extensions" API only works with the default interpreter in a case where an extension-created thread is not already associated with a Python thread state (and therefore an interpreter). But, by definition that's all it *can* do, unless it grew an option for the extension to specify an interpreter.
There may actually be a few other caveats, but as far as I can tell, all of these caveats are specific to extension modules. As a practical matter, mod_python uses the CPython multi-interpreter API now, and Jython has its own multi-interpreter API. (Strangely, IronPython seems to be strictly single-interpreter, or at least the first release of it was; I'm not sure why.)
_______________________________________________ Distutils-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/distutils-sig
