On 9 Jan 2003 at 14:23, Tim Peters wrote:
Someone who cares about multiple interpreter states should feel free to define and propose a stronger requirement. However, the people pushing for change here have explicitly disavowed interest in multiple interpreter states, and I'm happy to press on leaving them for afterthoughts.
I have used multiple interpreter states, but not because I wanted to. Consider in-process COM servers implemented in Python. When an application asks for the COM server, the COM support code will do the *loading* on a thread spawned by the COM support code. When the application *uses* the COM server, it may do so on it's own thread (it will certainly do so on a different thread than was used to load the server). Installer freezes in-process COM servers. It does so by using a generic shim dll which gets renamed for each component. Basically, this dll will forward most of the calls on to Mark's PythoncomXX.dll. But it wants to install import hooks. If it is the only Python in the process, everything is fine. But if the application is Python, or the user wants to load more than one Python based COM server, then there already is an interpreter state. Unfortunately, the shim dll can't get to it, so can't install it's import hooks into the right one. At least, that's my recollection of the problems I was having before I gave up. My understanding of COM is relatively superficial. I understand the Python part better, but certainly not completely, (there were things I thought *should* work that I couldn't get working). There may even be a reason to want multiple interpreter states. My understanding of COM and threading is not deep enough for me to make a coherent statement of requirements. But pretty clearly Python's thread API doesn't let me get anywhere close to handling multiple Pythons in one process. -- Gordon http://www.mcmillan-inc.com/