[Distutils] Standardizing distribution of "plugins" for extensible apps

[Phillip J. Eby]

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