Re: [IronPython] Global and Local ScriptScope
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
> 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
> 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
> 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 for my locals.
>
> This allowed my to do the following:
>
> PythonEngine pe = new PythonEngine();
> Context = pe.CreateModule();
> pe.Execute(ExpensiveGlobalSetupScript,Context);
> Dictionary[] locals = new
> Dictionary[ScriptList.Length];
> for(int i = 0; i < ScriptList.Length; i++)
> {
> locals[i] = new Dictionary()
> 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));
> }
>
Re: [IronPython] Global and Local ScriptScope
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
mailto: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
mailto: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
mailto: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 for my locals.
This allowed my to do the following:
PythonEngine pe = new PythonEngine();
Context = pe.CreateModule();
pe.Execute(ExpensiveGlobalSetupScript,Context);
Dictionary[] locals = new
Dictionary[ScriptList.Length];
for(int i = 0; i < ScriptList.Length; i++)
{
locals[i] = new Dictionary()
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<mailto:Users@lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com<mailto:Users@lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
__
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 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 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
>> 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 for my locals.
>>>
>>> This allowed my to do the following:
>>>
>>> PythonEngine pe = new PythonEngine();
>>> Context = pe.CreateModule();
>>> pe.Execute(ExpensiveGlobalSetupScript,Context);
>>> Dictionary[] locals = new
>>> Dictionary[ScriptList.Length];
>>> for(int i = 0; i < ScriptList.Length; i++)
>>> {
>>> locals[i] = new Dictionary()
>>> 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
Re: [IronPython] Global and Local ScriptScope
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 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
> 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 for my locals.
>>
>> This allowed my to do the following:
>>
>> PythonEngine pe = new PythonEngine();
>> Context = pe.CreateModule();
>> pe.Execute(ExpensiveGlobalSetupScript,Context);
>> Dictionary[] locals = new
>> Dictionary[ScriptList.Length];
>> for(int i = 0; i < ScriptList.Length; i++)
>> {
>> locals[i] = new Dictionary()
>> 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
Re: [IronPython] Global and Local ScriptScope
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 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 for my locals.
>
> This allowed my to do the following:
>
> PythonEngine pe = new PythonEngine();
> Context = pe.CreateModule();
> pe.Execute(ExpensiveGlobalSetupScript,Context);
> Dictionary[] locals = new
> Dictionary[ScriptList.Length];
> for(int i = 0; i < ScriptList.Length; i++)
> {
> locals[i] = new Dictionary()
> 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
[IronPython] Global and Local ScriptScope
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 for my locals.
This allowed my to do the following:
PythonEngine pe = new PythonEngine();
Context = pe.CreateModule();
pe.Execute(ExpensiveGlobalSetupScript,Context);
Dictionary[] locals = new
Dictionary[ScriptList.Length];
for(int i = 0; i < ScriptList.Length; i++)
{
locals[i] = new Dictionary()
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
