[IronPython] Global and Local ScriptScope

[Caspar Lessing]

That answers my question. Thanx guys.

Regards
Caz

On Tue, Jan 6, 2009 at 10:59 PM, Tomas Matousek <
Tomas.Matousek at 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-bounces at lists.ironpython.com [mailto:
> users-bounces at 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.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();
> 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 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
>
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090107/1a520873/attachment.html>