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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20050921/fc6cd7fe/smime-0001.bin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4