>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
GvR> It was always feature number one requested by folks coming
GvR> from Tcl, where creating multiple interpreters (threaded or
GvR> not) is an acceptable pastime for people of good manners.
GvR> But it seems to be wasted on the average Pythoneer.
GvR> In Python, there's one good use I can think of: an
GvR> application may embed Python and occasionally want to run a
GvR> good chunk of Python code. If it needs each chunk of Python
GvR> code to run completely independent from each other chunk,
GvR> creating a new interpreter for each chunk is a good way to
GvR> avoid that changes to e.g. sys.path or tabnanny's globals
GvR> made by one chunk affects the next chunk.
funny! in a previous life i wrote a large app that embedded tcl for
its configuration language. i did exactly as guido describes for
exactly that reason! in fact, in tcl, you could capture a complete
snapshot of the interpreter in tcl source, replay that into a fresh
interpreter and be back exactly where you started. a cheapo (but
effective) "save-game" like mechanism. haven't yet had the need to do
the same in python.
GvR> But apparently this habit has fallen in disuse -- from
GvR> looking at the code I believe there's a serious problem with
GvR> exceptions, where initializing the second interpreter messes
GvR> up the identities of the exception classes stored in global
GvR> variables by the first interpreter, and nobody has ever
GvR> complained about this. Or maybe they are still using Python
GvR> 1.5.2, which may not have the same problem. Or maybe this is
GvR> the reason why PyApache has a reptabion of instability. :(
i vaguely remember looking at this, and (i thought) fixing it, but
that memory's off-line through the weekend. :)
-barry