Ok, it's broken on 2.0.1 but not on 2.6. I've opened a 2.0.2 bug: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239
> -----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:47 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino Viehland wrote: > > And this works for me: > > > > I just did the equivalent, from *inside* IronPython which may make a > difference, with the 'os' module and got the opposite result: > > >>> import clr > >>> clr.AddReference('IronPython') > >>> from IronPython.Hosting import Python# > >>> e1 = Python.CreateEngine() > >>> e2 = Python.CreateEngine() > >>> > >>> os1 = Python.ImportModule(e1, 'os') > >>> os2 = Python.ImportModule(e2, 'os') > >>> > >>> os1 > <Microsoft.Scripting.Hosting.ScriptScope object at 0x000000000000002B > [Microsoft > .Scripting.Hosting.ScriptScope]> > >>> os1 is os2 > False > >>> os1.SetVariable('foo', 'bar') > >>> os2.GetVariable('foo') > 'bar' > >>> > > > All the best, > > Michael > > > 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 > > > > > -- > 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
