2.6, 3.0, and truly independent intepreters
andy55 at gmail.com
Wed Oct 22 20:45:47 CEST 2008
Hi Thomas -
I appreciate your thoughts and time on this subject.
> The result is that separate COM objects implemented as Python modules and
> converted into separate dlls by py2exe do not share their interpreters even
> if they are running in the same process. Of course this only works on windows.
> In effect this is similar to using /statically/ linked python interpreters
> in separate dlls. Can't you do something like that?
You're definitely correct that homebrew loading and linking would do
the trick. However, because our python stuff makes callbacks into our
C/C++, that complicates the linking process (if I understand you
correctly). Also, then there's the problem of OS X.
> > - In python 3, the C module API now supports true interpreter
> > independence, but have all the modules in the python codebase been
> > converted over? Are they all now truly compliant? It will only take
> > a single static/global state variable in a module to potentially cause
> > no end of pain in a multiple interpreter environment! Yikes!
> I don't think this is the case (currently). But you could submit patches
> to Python so that at least the 'official' modules (builtin and extensions)
> would behave corectly in the case of multiple interpreters. At least
> this is a much lighter task than writing your own GIL-less interpreter.
I agree -- and I've been considering that (or rather, having our
company hire/pay part of the python dev community to do the work). To
consider that, the question becomes, how many modules are we talking
about do you think? 10? 100? I confess that I'm no familiar enough
with the full C python suite to have a good idea of how much work
we're talking about here.
More information about the Python-list