Adam Olsen added the comment: mwh, my threading patch is extensive enough and has enough overlap that I'm not intimidating by fixing this. It's low on my list of priorities though.
So far my tendency is to rip out multiple interpreters, as I haven't seen what it wants to accomplish. It's certainly *NOT* completely isolated interpreters. As for Py_Finalize, I see 4 purposes to calling it: 1) Finish any lingering bits of the program, such as __del__ methods or weakref callbacks 2) Delete lingering references so refcount errors or memory leaks may be more easily discovered 3) Prepare for Py_Initialize to be called again 4) Return the interpreter to a quiescent state such that python.so can be safely unloaded, then reloaded and Py_Initialize called again Of these, 3 and 4 are not done. 3 would be easy if Py_Finalize was a no-op, but that'd undermine 1 and 2. Given the optimistic documentation, it's surprising how limited Py_Finalize's scope is. I've seen some fleeting discussion of allowing extension modules to be unloaded, which IMO requires returning them to a quiescent state. Doing that may lay the foundation for doing it to the entire interpreter. Anyway, real use cases are critical here. Although you may think you want your plugins to unload python, the costs mean you should only do so very rarely, enough that there's really no advantage to unloading it (except at program shutdown, for purposes 1 and 2.) _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1225584> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
