[IronPython] Global and Local ScriptScope
curt at hagenlocher.org
Tue Jan 6 21:39:57 CET 2009
Scopes are intended for the language-implementation side of things.
Python does not. Even if we were to expose a mechanism in the hosting API
that let you create ScriptScopes which reference nested Scopes, there's no
guarantee that Python's name resolution would automatically work with this.
You shouldn't need to define your own implementation of
IAttributesCollection. Can't you just use the SymbolDictionary defined in
Microsoft.Scripting and fill it manually?
On Tue, Jan 6, 2009 at 12:07 PM, Caspar Lessing <caspar.lessing at gmail.com>wrote:
> You are right, it is basically a "from pricy_scope import *" for each one
> of my local scopes.
> I considered doing that, but decided against it as I'm really loathe to
> copy the context a whole bunch of times. The number of symbols _should_ not
> be excessive but the pricy_scope setup script is configuration and
> eventually could have a fair amount of symbols. The number of local contexts
> however will be fairly high. Thousands to 10s of thousands. So copying gets
> multiplied by that. So I am trying hard not do the copying thing.
> However the Scope Parent mechanism is perfectly suited for wat I need. So I
> was hoping I could use that which means no copying required.
> On Tue, Jan 6, 2009 at 4:56 PM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>> How many symbols are there in this shared global context? Can't you just
>> initialize them in one ScriptScope and then copy the symbols into the other
>> ScriptScopes where you want to use them? This would be analogous to saying
>> "from pricy_scope import *" at the beginning of each module.
>> On Tue, Jan 6, 2009 at 5:58 AM, Caspar Lessing <caspar.lessing at gmail.com>wrote:
>>> Hello People
>>> I use an embedded instance of IronPython.
>>> My program spends effort to create a global context. It then continues to
>>> to execute statements inside a local context which need resolve the items in
>>> the global context as well. Think of python functions' local context and its
>>> interaction with the module context.
>>> In an older version of IronPython I had a EngineModule which I used for
>>> my global context and I could use a Dictionary<string,object> for my locals.
>>> This allowed my to do the following:
>>> PythonEngine pe = new PythonEngine();
>>> Context = pe.CreateModule();
>>> Dictionary<string,object> locals = new
>>> for(int i = 0; i < ScriptList.Length; i++)
>>> locals[i] = new Dictionary<string,object>()
>>> pe.Execute(ScriptList[i], Context, locals[i]);
>>> I am having trouble doing something similar with ScriptScope. I have
>>> explored some avenues:
>>> 1. Copying the global context into each local one. It seems too
>>> expensive. Possibly it is only the cloning of some form of dictionary, but
>>> 2. Implementing a new CustomSymbolDictionary and overriding
>>> TryGetExtraValue. Problem is that it is called before trying to resolve
>>> symbols internally (Which leads to globals being resolved rather than
>>> 3. Creating my own implementation of IAttributesCollection (Seemed too
>>> complex after discovering the Parent mechanism in Scope)
>>> I eventually found the Parent mechanism inside Scope. However I do not
>>> have access to create a new ScriptScope (Internal constructor) based on a
>>> Parent Scope.
>>> I had to create a new Factory method inside ScriptEngine which looks as
>>> public sealed class ScriptEngine
>>> public ScriptScope CreateScope(ScriptScope parent)
>>> ContractUtils.RequiresNotNull(parent, "parent");
>>> return new ScriptScope(this, new Scope(parent.Scope,null));
>>> My question if whether this is a sensible addition to ScriptEngine or am
>>> I missing something?
>>> Much appreciated
>>> Users mailing list
>>> Users at lists.ironpython.com
>> Users mailing list
>> Users at lists.ironpython.com
> Users mailing list
> Users at lists.ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironpython-users