That answers my question. Thanx guys.
Regards
Caz
On Tue, Jan 6, 2009 at 10:59 PM, Tomas Matousek <
tomas.matou...@microsoft.com> wrote:
> The current scope chaining is rather a remnant of a legacy technique of
> using Scopes for local variables in IronPython and JScript. The hosting API
> doesn't support chaining by design (this might change in future). The best
> option for you for now, I think, is to implement IAttributesCollection. That
> is the way the host should customize scope variable lookup. What we need to
> do on our side is to simplify this interface.
>
>
>
> Tomas
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Curt Hagenlocher
> *Sent:* Tuesday, January 06, 2009 12:40 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Global and Local ScriptScope
>
>
>
> Scopes are intended for the language-implementation side of things.
> Languages like Ruby and Javascript support nested lexical scoping but
> 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.less...@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 <c...@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.less...@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();
> pe.Execute(ExpensiveGlobalSetupScript,Context);
> Dictionary<string,object>[] locals = new
> Dictionary<string,object>[ScriptList.Length];
> 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 still.
> 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
> locals)
> 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
> follows:
>
> 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
> Caz
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
