> If you are going to make a comment such as 'multi-interpreter feature > doesn't really work' you really should substantiate it by pointing to > where it is documented what the problems are or enumerate yourself > exactly what the issues are. There is already enough FUD being spread > around about the ability to run multiple sub interpreters in an > embedded Python application, so adding more doesn't help.
I don't think the limitations have been documented in a systematic manner. Some of the problems I know of are: - objects can easily get shared across interpreters, and often are. This is particularly true for static variables that extensions keep, and for static type objects. - Py_EndInterpreter doesn't guarantee that all objects are released, and may leak. This is the problem that the OP seems to have. All it does is to clear modules, sys, builtins, and a few other things; it is then up to reference counting and the cycle GC whether this releases all memory or not. - the mechanism of PEP 311 doesn't work for multiple interpreters. > Oh, it would also be nice to know exactly what embedded systems you > have developed which make use of multiple sub interpreters so we can > gauge with what standing you have to make such a comment. I have never used that feature myself. However, I wrote PEP 3121 to overcome some of its limitations. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
