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
