Re: [IronPython] .NET Attributes
I like this too... It's interesting that while the syntax isn't exactly the same for giving both classes & functions attributes they are both getting that information in the same way. I was previously worried about the differences between classes & functions but I think this brings it all together. From: [EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Monday, March 27, 2006 8:58 PM To: Discussion of IronPython Subject: Re: [IronPython] .NET Attributes 2006/3/28, Sanghyeon Seo <[EMAIL PROTECTED]>: > I like __attributes__ solution. As pointed out already, decorators can't be used with classes as of 2.4. But __attributes__ can be attached to classes or functions. I agree that decorators would be nice. Perhaps something like the following in clr module? def f(arg): pass f.__attributes__ = [Foo(), Bar(1)] equivalent to: @attributes(Foo(), Bar(1)) def f(arg): pass where cool_attributes = attributes(Foo(), Bar(1)) @cool_attributes def f(arg): pass @cool_attributes def g(arg): pass is possible. Just my 2c. Seo Sanghyeon ___ 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] .NET Attributes
2006/3/28, Sanghyeon Seo <[EMAIL PROTECTED]>: > I like __attributes__ solution. As pointed out already, decorators can't be used with classes as of 2.4. But __attributes__ can be attached to classes or functions. I agree that decorators would be nice. Perhaps something like the following in clr module? def f(arg): pass f.__attributes__ = [Foo(), Bar(1)] equivalent to: @attributes(Foo(), Bar(1)) def f(arg): pass where cool_attributes = attributes(Foo(), Bar(1)) @cool_attributes def f(arg): pass @cool_attributes def g(arg): pass is possible. Just my 2c. Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET Attributes
2006/3/28, Dino Viehland <[EMAIL PROTECTED]>: The second problem is also just as tough, but it's completely different. How do you even express an attribute on a class? There's no Python syntax for this so we'd have to add something new. It'd be great if we could use decorators here, but they don't apply to classes. So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here... * * * I like __attributes__ solution. Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET Attributes
My only point is that new decorators shouldn't be included unless they are available in the language. I know Guido said something about them at PyCon but I can't remember what :)I have no problems with decorators by the way. Cherrypy (a web framework/library) uses a decorator-ish syntax, so if implementing a library for working around .NET details and IronPython is needed, it would not be out of line to use a decorator. I just think the close CPython and IronPython can be, the better it is for everyone. EricOn 3/27/06, Keith J. Farmer <[EMAIL PROTECTED]> wrote: For the purposes of consistency, the attribute decorators would need to apply everywhere an attribute is able to exist in .NET: types, members, etc.In the case of Serializable, merely subclassing ISerializable isn't necessarily the best way, since a class can be decorated with SerializableAttribute instead. Would magic comments be sufficient? eg// ATTRIBUTE: Serializeableclass MyClass(FooBase):// ATTRIBUTE: MyMemberAttributedef Foo():(Forgive my Python -- it's a little rusty...) Actually, wasn't there a PEP regarding decorators?___users mailing listusers@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] what version of IronPython works with mono 1.1.13.4?
1.1.13.4 should work with IronPython, but you seem to be running it inside xsp, which is a net 1.1 app. Try using 'xsp2'. Zoltan On 3/27/06, Mathew Yeates <[EMAIL PROTECTED]> wrote: > Hi > I'm using mono 1.1.13.4 and calls to IronPython 1.0 Beta 4 cause a segv. > What version of IronPython works?? > Mathew > > > ** (/home/myeates/mono-1.1.13.4/lib/xsp/1.0/xsp.exe:20873): WARNING **: > The class System.Collections.Generic.IDictionary`2 could not be loaded, > used in mscorlib, Version=2.0.0.0, Culture=neutral, > PublicKeyToken=b77a5c561934e089 > > = > Got a SIGSEGV while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > = > > Stacktrace: > in WebService100.Service1:HelloWorld (int) <0x> > in WebService100.Service1:HelloWorld (int) <0x24> > in (wrapper runtime-invoke) System.Object:runtime_invoke_string_int > (object,intptr,intptr,intptr) <0x74eaf9f> > in (wrapper managed-to-native) > System.Reflection.MonoMethod:InternalInvoke (object,object[]) <0x4> > in (wrapper managed-to-native) > System.Reflection.MonoMethod:InternalInvoke (object,object[]) <0xffdf651d> > in System.Reflection.MonoMethod:Invoke > (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) > <0x8d> > in System.Reflection.MethodBase:Invoke (object,object[]) <0x1a> > in System.Web.Services.Protocols.LogicalMethodInfo:Invoke > (object,object[]) <0x88> > in System.Web.Services.Protocols.HttpSimpleWebServiceHandler:Invoke > (System.Web.Services.Protocols.LogicalMethodInfo,object[]) <0x41> > in > System.Web.Services.Protocols.HttpSimpleWebServiceHandler:ProcessRequest > (System.Web.HttpContext) <0x143> > in __1:MoveNext () <0x10a0> > in System.Web.HttpApplication:Tick () <0x1f> > in System.Web.HttpApplication:Start (object) <0x37> > in > System.Web.HttpApplication:System.Web.IHttpAsyncHandler.BeginProcessRequest > (System.Web.HttpContext,System.AsyncCallback,object) <0x68> > in System.Web.HttpRuntime:RealProcessRequest (object) <0x1ab> > in Mono.WebServer.BaseApplicationHost:ProcessRequest > (Mono.WebServer.MonoWorkerRequest) <0x43> > in Mono.WebServer.XSPApplicationHost:ProcessRequest > (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) > <0x37f> > in (wrapper remoting-invoke-with-check) > Mono.WebServer.XSPApplicationHost:ProcessRequest > (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) > <0xfa6c> > in (wrapper xdomain-dispatch) > Mono.WebServer.XSPApplicationHost:ProcessRequest > (object,byte[]&,byte[]&,int,long,int,long,int,string,string,string,string,byte[],string) > <0x3ce4cb> > in (wrapper xdomain-invoke) > Mono.WebServer.XSPApplicationHost:ProcessRequest > (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) > <0xffc216c5> > in (wrapper remoting-invoke-with-check) > Mono.WebServer.XSPApplicationHost:ProcessRequest > (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) > <0x3eb0b> > in Mono.WebServer.XSPWorker:InnerRun (object) <0x563> > in Mono.WebServer.XSPWorker:Run (object) <0x22> > in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object > (object) <0xff95> > in (wrapper runtime-invoke) System.Object:runtime_invoke_void_object > (object,intptr,intptr,intptr) <0x78d82bf> > > > ___ > 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] what version of IronPython works with mono 1.1.13.4?
Hi I'm using mono 1.1.13.4 and calls to IronPython 1.0 Beta 4 cause a segv. What version of IronPython works?? Mathew ** (/home/myeates/mono-1.1.13.4/lib/xsp/1.0/xsp.exe:20873): WARNING **: The class System.Collections.Generic.IDictionary`2 could not be loaded, used in mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 = Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Stacktrace: in WebService100.Service1:HelloWorld (int) <0x> in WebService100.Service1:HelloWorld (int) <0x24> in (wrapper runtime-invoke) System.Object:runtime_invoke_string_int (object,intptr,intptr,intptr) <0x74eaf9f> in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) <0x4> in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) <0xffdf651d> in System.Reflection.MonoMethod:Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) <0x8d> in System.Reflection.MethodBase:Invoke (object,object[]) <0x1a> in System.Web.Services.Protocols.LogicalMethodInfo:Invoke (object,object[]) <0x88> in System.Web.Services.Protocols.HttpSimpleWebServiceHandler:Invoke (System.Web.Services.Protocols.LogicalMethodInfo,object[]) <0x41> in System.Web.Services.Protocols.HttpSimpleWebServiceHandler:ProcessRequest (System.Web.HttpContext) <0x143> in __1:MoveNext () <0x10a0> in System.Web.HttpApplication:Tick () <0x1f> in System.Web.HttpApplication:Start (object) <0x37> in System.Web.HttpApplication:System.Web.IHttpAsyncHandler.BeginProcessRequest (System.Web.HttpContext,System.AsyncCallback,object) <0x68> in System.Web.HttpRuntime:RealProcessRequest (object) <0x1ab> in Mono.WebServer.BaseApplicationHost:ProcessRequest (Mono.WebServer.MonoWorkerRequest) <0x43> in Mono.WebServer.XSPApplicationHost:ProcessRequest (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) <0x37f> in (wrapper remoting-invoke-with-check) Mono.WebServer.XSPApplicationHost:ProcessRequest (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) <0xfa6c> in (wrapper xdomain-dispatch) Mono.WebServer.XSPApplicationHost:ProcessRequest (object,byte[]&,byte[]&,int,long,int,long,int,string,string,string,string,byte[],string) <0x3ce4cb> in (wrapper xdomain-invoke) Mono.WebServer.XSPApplicationHost:ProcessRequest (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) <0xffc216c5> in (wrapper remoting-invoke-with-check) Mono.WebServer.XSPApplicationHost:ProcessRequest (int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) <0x3eb0b> in Mono.WebServer.XSPWorker:InnerRun (object) <0x563> in Mono.WebServer.XSPWorker:Run (object) <0x22> in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object (object) <0xff95> in (wrapper runtime-invoke) System.Object:runtime_invoke_void_object (object,intptr,intptr,intptr) <0x78d82bf> ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET Attributes
For the purposes of consistency, the attribute decorators would need to apply everywhere an attribute is able to exist in .NET: types, members, etc. In the case of Serializable, merely subclassing ISerializable isn't necessarily the best way, since a class can be decorated with SerializableAttribute instead. Would magic comments be sufficient? eg // ATTRIBUTE: Serializeable class MyClass(FooBase): // ATTRIBUTE: MyMemberAttribute def Foo(): (Forgive my Python -- it's a little rusty...) Actually, wasn't there a PEP regarding decorators? <>___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET Attributes
This is great feedback…. And yet another way we could consider doing this would be something whacky with metaclasses where we had an “attribute-aware” metaclass or something like that… But it demonstrates the difficulty in adding support for features like this and the reason we need to tread lightly here. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Larson Sent: Monday, March 27, 2006 9:11 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET Attributes On the topic of decorators and integrating with .NET, it seems that in order to keep IronPython as close to CPython, it would be a good idea to consider adding .NET specific pieces as a "library" instead of an addition to the language. That way people could write python code that works in IronPython and CPython equally well without changing radically how the code is written. For example, if I wanted to make a class serializable, it seems logical to inherit from some serializable base class. from clr.netisms import IPSerializable class MyClass(IPSerializable): This may be an obvious solution, but it seems to make more sense to add IronPython specific libraries to help integrate with .NET than to pollute the language. I mention this because one of the great things about Python is the "batteries included" mentality. There are many great libraries that would be excellent to run using IronPython (ZODB for example) that may conflict if the language gets massaged to fit into .NET perfectly. Often times writing to the lowest common denominator can be bad (SQL portability for example), but I believe in the case of Python, whatever can be done to work with the massive amount of libraries will be the most beneficial. I apologize if this is already addressed. I am thinking about issues such as these from a python programmer's perspective. Great work! Eric On 3/27/06, Dino Viehland <[EMAIL PROTECTED]> wrote: This is a tough problem... There are two issues here. But the executive summary here is I'd say the earliest you should *expect* to see this is 1.1, but if (somehow) we end up with some extra time we might have something in the 1.0 timeframe (but don't hold your breath!). The first issue here is that when your code gets compiled we don't create what are truly .NET classes. Let's forget about old-style classes for a second (as those are REALLY not .NET classes, and never will be) and instead focus on new-style classes. When you define a class we'll see if anyone else has inherited from the same set of base-types (including .NET interfaces). If someone has then we'll use that class instead of creating a new class. If they haven't we'll derive a new class from your base-class set, overriding all of the virtual methods, and creating some new fields like __dict__ and __class__. Those fields allow us to both allow you to change the type of your classes at runtime as well as attach new properties to instances. They also allow us to create a limited number of CLR types (which aren't garbage collected) which means long-running programs creating lots of types don't leak. In the end there's not really anything good for us to attach the attributes to. To get that we'd need to move to a more static-compilation model while at the same time retaining the ability to do all the great dynamic stuff with Python. It's a hard problem and one that we simply haven't solved yet. The second problem is also just as tough, but it's completely different. How do you even express an attribute on a class? There's no Python syntax for this so we'd have to add something new. It'd be great if we could use decorators here, but they don't apply to classes. So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here... Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038 ) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Andrzej Krzywda Sent: Monday, March 27, 2006 4:55 AM To: users@lists.ironpython.com Subject: [IronPython] .NET Attributes Hi, When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable? -- Andrzej ___ 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.ironpy
Re: [IronPython] .NET Attributes
On the topic of decorators and integrating with .NET, it seems that in order to keep IronPython as close to CPython, it would be a good idea to consider adding .NET specific pieces as a "library" instead of an addition to the language. That way people could write python code that works in IronPython and CPython equally well without changing radically how the code is written. For example, if I wanted to make a class serializable, it seems logical to inherit from some serializable base class. from clr.netisms import IPSerializableclass MyClass(IPSerializable):This may be an obvious solution, but it seems to make more sense to add IronPython specific libraries to help integrate with .NET than to pollute the language. I mention this because one of the great things about Python is the "batteries included" mentality. There are many great libraries that would be excellent to run using IronPython (ZODB for example) that may conflict if the language gets massaged to fit into .NET perfectly. Often times writing to the lowest common denominator can be bad (SQL portability for example), but I believe in the case of Python, whatever can be done to work with the massive amount of libraries will be the most beneficial. I apologize if this is already addressed. I am thinking about issues such as these from a python programmer's perspective.Great work!EricOn 3/27/06, Dino Viehland <[EMAIL PROTECTED]> wrote: This is a tough problem... There are two issues here. But the executive summary here is I'd say the earliest you should *expect* to see this is 1.1, but if (somehow) we end up with some extra time we might have something in the 1.0 timeframe (but don't hold your breath!).The first issue here is that when your code gets compiled we don't create what are truly .NET classes. Let's forget about old-style classes for a second (as those are REALLY not .NET classes, and never will be) and instead focus on new-style classes. When you define a class we'll see if anyone else has inherited from the same set of base-types (including .NET interfaces). If someone has then we'll use that class instead of creating a new class. If they haven't we'll derive a new class from your base-class set, overriding all of the virtual methods, and creating some new fields like __dict__ and __class__. Those fields allow us to both allow you to change the type of your classes at runtime as well as attach new properties to instances. They also allow us to create a limited number of CLR types (which aren't garbage collected) which means long-running programs creating lots of types don't leak. In the end there's not really anything good for us to attach the attributes to. To get that we'd need to move to a more static-compilation model while at the same time retaining the ability to do all the great dynamic stuff with Python. It's a hard problem and one that we simply haven't solved yet. The second problem is also just as tough, but it's completely different. How do you even express an attribute on a class? There's no Python syntax for this so we'd have to add something new. It'd be great if we could use decorators here, but they don't apply to classes. So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here... Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038 )-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Andrzej KrzywdaSent: Monday, March 27, 2006 4:55 AMTo: users@lists.ironpython.comSubject: [IronPython] .NET AttributesHi,When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable?--Andrzej___users mailing listusers@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com___users mailing list users@lists.ironpython.comhttp://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] .NET Attributes
This is a tough problem... There are two issues here. But the executive summary here is I'd say the earliest you should *expect* to see this is 1.1, but if (somehow) we end up with some extra time we might have something in the 1.0 timeframe (but don't hold your breath!). The first issue here is that when your code gets compiled we don't create what are truly .NET classes. Let's forget about old-style classes for a second (as those are REALLY not .NET classes, and never will be) and instead focus on new-style classes. When you define a class we'll see if anyone else has inherited from the same set of base-types (including .NET interfaces). If someone has then we'll use that class instead of creating a new class. If they haven't we'll derive a new class from your base-class set, overriding all of the virtual methods, and creating some new fields like __dict__ and __class__. Those fields allow us to both allow you to change the type of your classes at runtime as well as attach new properties to instances. They also allow us to create a limited number of CLR types (which aren't garbage collected) which means long-running programs creating lots of types don't leak. In the end there's not really anything good for us to attach the attributes to. To get that we'd need to move to a more static-compilation model while at the same time retaining the ability to do all the great dynamic stuff with Python. It's a hard problem and one that we simply haven't solved yet. The second problem is also just as tough, but it's completely different. How do you even express an attribute on a class? There's no Python syntax for this so we'd have to add something new. It'd be great if we could use decorators here, but they don't apply to classes. So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here... Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrzej Krzywda Sent: Monday, March 27, 2006 4:55 AM To: users@lists.ironpython.com Subject: [IronPython] .NET Attributes Hi, When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable? -- Andrzej ___ 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] Updating globals()
Did you run it at the console or from a file you imported?
IronPython will actually use different underlying CLR dictionary objects
depending on how the code gets compiled (which is the reason why this compiles
in one spot but not another).
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rene Olsthoorn
Sent: Monday, March 27, 2006 12:52 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Updating globals()
Hello Seo,
On Windows XP, it runs without a problem.
Greets, Rene Olsthoorn.
On 3/27/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> Updating module-level globals() raises AttributeError.
>
> vars = {'a': 1, 'b': 2}
> globals().update(vars)
> print a, b
>
> Seo Sanghyeon
> ___
> 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] Updating globals()
Thanks for the bug report Seo. I can repro this on our current builds and have
filed the bug. I think we'll be able to get this one fixed for beta 5.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Monday, March 27, 2006 12:26 AM
To: Discussion of IronPython
Subject: [IronPython] Updating globals()
Updating module-level globals() raises AttributeError.
vars = {'a': 1, 'b': 2}
globals().update(vars)
print a, b
Seo Sanghyeon
___
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] .NET Attributes
Hi, When there will be support for .NET Attributes in IronPython? Is there any way currently to mark my class as Serializable? -- Andrzej ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Updating globals()
2006/3/27, Rene Olsthoorn <[EMAIL PROTECTED]>: > On Windows XP, it runs without a problem. Strange, I can reproduce this on Windows XP too. Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Updating globals()
Hello Seo,
On Windows XP, it runs without a problem.
Greets, Rene Olsthoorn.
On 3/27/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> Updating module-level globals() raises AttributeError.
>
> vars = {'a': 1, 'b': 2}
> globals().update(vars)
> print a, b
>
> Seo Sanghyeon
> ___
> 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] Updating globals()
2006/3/27, Sanghyeon Seo <[EMAIL PROTECTED]>: > Updating module-level globals() raises AttributeError. This happens only when run from the file. Interactive console is fine. Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Updating globals()
Updating module-level globals() raises AttributeError.
vars = {'a': 1, 'b': 2}
globals().update(vars)
print a, b
Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
