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 -- http://mail.python.org/mailman/listinfo/python-list