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-bounces at lists.ironpython.com [mailto:users-
>>bounces at 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-bounces at lists.ironpython.com>>> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto,
>>> Stephen P
>>> *Sent:* Thursday, April 30, 2009 8:26 AM
>>> *To:* users at 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 at lists.ironpython.com>>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>>>>>>>> --
>>http://www.ironpythoninaction.com/>>>> _______________________________________________
>> Users mailing list
>>Users at lists.ironpython.com>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>>>> _______________________________________________
> Users mailing list
>Users at lists.ironpython.com>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
--
http://www.ironpythoninaction.com/