If you import by executing the text "import <modname>" against the ScriptEngine instead of using the import API, you will avoid this particular incarnation of the bug.
On Thu, Apr 30, 2009 at 10:25 AM, Lepisto, Stephen P < [email protected]> wrote: > I voted for fixing the bug. In the meantime, I will be putting on hold the > use of IronPython as an embedded language in my project until this is fixed > or IronPython 2.6 is released (if I can convince my manager and team it's a > good idea to move to python 2.6 but it will affect a lot of people). > > Thank you for the prompt responses! > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Dino Viehland > Sent: Thursday, April 30, 2009 10:23 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions > in a single process > > 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: [email protected] [mailto:users- > > [email protected]] 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: [email protected] [mailto:users- > > [email protected]] 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: [email protected] [mailto:users- > > > [email protected]] 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:* [email protected] > > > > [mailto:[email protected]] *On Behalf Of *Lepisto, > > > > Stephen P > > > > *Sent:* Thursday, April 30, 2009 8:26 AM > > > > *To:* [email protected] > > > > *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 > > > > [email protected] > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > > > > -- > > > http://www.ironpythoninaction.com/ > > > > > > _______________________________________________ > > > Users mailing list > > > [email protected] > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
