Issue2465

The ugly truth of the PythonInterpreter class, now that I have looked at the source, seems to be that by default it shares PySystemState objects between instances of PythonInterpreters. This means that having more than one PythonInterpreter won't share local variables, but it WILL share imports and sys.path and a bunch of other things.

If I truly want independent PythonInterpreter objects, I have to create my own PySystemState object for each interpreter. This is easy, but there is no function that helps setup the PySystemState object properly without relying on static mutable state. I'm looking at you, PySystemState.doInitialize() -- lots of goodies here but it acts upon the default system state and there is no way to do the same thing on an independent PySystemState object without duplicating lots of pieces of source code and trying to remove static mutable state. >:(

So I did some refactoring PySystemState for 2.7, but I was unable to get rid of all the ugliness in doInitialize around static mutable state.

Maybe it's something we can completely re-address in Jython 3.x?

But having functionality to help do such PySystemState setup, as Jason suggests, is something we can definitely look at for 2.7.2. We can look at design ideas here for a clean API to manage PythonInterpreter/PySystemState lifecycle, then move to jython-dev for a final discussion.

We definitely haven't taken that "look at design ideas here" as Jim invites us (meaning on this ticket, I think). However, jython-dev is a probably the better place from the start (once Sourceforge recovers) as everyone likely to care is subscribed to that.

I think this has interesting architectural implications and we're not likely to do the right thing in time for 2.7.2.