Bob Ippolito <[EMAIL PROTECTED]> writes: > Personally my biggest issue with the way the CPython VM works is that > you can't reliably do multiple interpreters in a single process. If > that worked well, you could start an independent interpreter per > thread and with a per-interpreter GIL you'd have pretty much > everything you needed... but this would horribly break the C API and > may be a performance hit. > > My use case for this isn't so much about threads, but plug-ins. > Writing multiple Python-based plug-ins for an application is always a > mess, because they share too much (sys.modules, sys.path, etc.). > PyObjC would benefit greatly from this feature, because you can write > Python-based plug-ins for any Cocoa app that supports plug-ins, even > if they're otherwise unaware of Python's existence. There are > workarounds, of course, with import hooks and similar hacks. I think > that mod_python would also benefit from this, and probably other such > systems.
Just a note in case you didn't know this already, probably off-topic for python-dev, but not meant as advertisement for py2exe): the same (plug-in) problem occurs with an inprocess COM server and a Python client program, or more than one inproc COM server in any client program. The 0.6 py2exe release with it's bundle-file option allows to build COM dlls (and client EXE programs, if needed) that APPEAR to have a statically linked copy of Python##.dll, and so have several CPython VMs running in the same process. In case anybody want's to take a look or experiment with it. Thomas _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
