Looks like our threads crossed. Yep, I was using the current 2.6 branch. I opened a bug to fix this in 2.0.2 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239).
Thanks for reporting this - this is a very bad bug. > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P > Sent: Thursday, April 30, 2009 10:10 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino, > > That example you provided produced the following output under > IronPython 2.0.1: > > hello > 42 > > In other words, the two sessions appear to be sharing the same module > in IronPython 2.0.1. > > Are you using a later version of IronPython where this might be fixed? > > > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Thursday, April 30, 2009 9:28 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > And this works for me: > > using System; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > > class foo { > static void Main(string[] args) > { > var engine = Python.CreateEngine(); > ScriptScope scope1 = engine.ImportModule("foo"); > > var engine2 = Python.CreateEngine(); > ScriptScope scope2 = engine2.ImportModule("foo"); > > scope1.SetVariable("foo", 42); > object res; > if(scope2.TryGetVariable("foo", out res)) { > Console.WriteLine(res); > } else { > Console.WriteLine("no foo"); > } > } > } > > Foo.py: > print 'hello' > > Printing out: > > hello > hello > no foo > > > -----Original Message----- > > From: users-boun...@lists.ironpython.com [mailto:users- > > boun...@lists.ironpython.com] On Behalf Of Michael Foord > > Sent: Thursday, April 30, 2009 9:08 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Dino Viehland wrote: > > > > > > You mention CreateEngine but are you also creating multiple > runtimes? > > > You're only allowed 1 ScriptEngine of a given type per > ScriptRuntime. > > > So you should create a new ScriptRuntime and then get the Python > > > engine for each runtime and then be isolated. > > > > > > > If you call Python.CreateEngine() twice it gives you two different > > engine objects with what *appear* to be different runtimes. > > > > If you then call Python.ImportModule for the same module but passing > in > > the two different engines, you get two different (non-identical > > objects) > > ScriptScopes - but changes in one are reflected in the other. > > > > Is CreateEngine not the correct way to get isolated engines? > > > > Michael > > > > > *From:* users-boun...@lists.ironpython.com > > > [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto, > > > Stephen P > > > *Sent:* Thursday, April 30, 2009 8:26 AM > > > *To:* users@lists.ironpython.com > > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > > sessions in a single process > > > > > > Hello, everyone! > > > > > > I am working on an service manager application that provides > embedded > > > python support through a small set of generalized classes: > > > PythonService, PythonSession, and PythonClass. A client application > > > asks the service manager for the PythonService object and then asks > > > the PythonService object for a new PythonSession object. The > > > PythonSession object is used to access embedded python through a > > small > > > set of generalized methods. The PythonClass object is used to wrap > a > > > python class instance. > > > > > > The key requirement in this is each client must have its own python > > > session, independent of any other sessions currently running. I've > > got > > > this to work with CPython (specifically, python 2.5.4), by careful > > use > > > of the global interpreter lock and swapping the thread state. > > > IronPython 2.0.1 has a nicer way of implementing all of this by > using > > > the CreateEngine() to create a new python engine. However, in > > > IronPython I've run into what appears to be a significant > limitation > > > that may prevent me from using IronPython in this particular > > situation > > > as an embedded language. > > > > > > The limitation is when I import a python package from disk into > > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > > session and then import the same package into a different session, > it > > > turns out that both sessions are pulling from the same module's > > scope. > > > That is, if I make changes to the module's scope in one session > (for > > > example, changing a global variable), that change appears in the > > other > > > session. > > > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > > that a module is cached in the LanguageContext (PythonContext) > > object, > > > which in turn is a singleton in DLR, as it is associated with the > > > language type. This is okay if an application is embedding > IronPython > > > itself but in my scenario, this prevents multiple discrete python > > > sessions in a single application. Ideally, I would expect to see > the > > > system state be stored in the python engine (ScriptEngine) or > python > > > runtime (ScriptRuntime) objects. > > > > > > Is there a way around this limitation? Can I somehow create a > unique > > > PythonContext object for each of my python sessions so I get a > > > completely discrete python instance in each session with no > > crosstalk? > > > Or do I have to resort to modifying the IronPython source to > > > accomplish this (which I'm loathe to do since then I would have to > > > maintain it going forward)? > > > > > > Thank you for your time and consideration in this matter. > > > > > > ------------------------------------------------------------------- > -- > > --- > > > > > > _______________________________________________ > > > Users mailing list > > > Users@lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > -- > > http://www.ironpythoninaction.com/ > > > > _______________________________________________ > > Users mailing list > > Users@lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com