2.6, 3.0, and truly independent intepreters

[Andy]

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.

Regards,
Andy