On 21-sep-2005, at 0:10, Bob Ippolito wrote:
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.
For PyObjC having multiple interpreters in a process would cause me severe headaches. Due to the nature of PyObjC it would be way too easy to accidently access objects from one interpreter in another interpreter (in a hypothetical universe where it would be easy to use multiple interpreters). And lets not get started about the GIL, I don't think its accidental that PyGILState_Ensure only works with one interpreter.
A system like Java's classloader would be helpfull, where the classloader of a class is used to load the classes used by that class. I have no idea if this can be adapted to python at all. A strict coding style seems to work for now.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
