[Distutils] Standardizing distribution of "plugins" for
Phillip J. Eby
pje at telecommunity.com
Wed Dec 8 19:03:41 CET 2004
At 04:31 PM 12/8/04 +0100, Thomas Heller wrote:
>"Phillip J. Eby" <pje at telecommunity.com> 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.)
More information about the Distutils-SIG