Re: [IronPython] i thought this is odd: using Interop on Microsoft Word
On Nov 1, 10:14 pm, Shri Borde <[EMAIL PROTECTED]> wrote: > This could be fixed in IronPython but currently its expected. > > docs[1] is calling into this indexer in Microsoft.Office.Interop.Word.dll. > The indexer method takes the index by-reference. Ie as "object&" instead of > just "object". Shri, thanks a lot for your detailed explanation. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
Dino Viehland wrote:
> Cool, I suspect it'll work fine on your laptop. Do you have Orcas beta 2
> installed or something else?
>
Sorry - have to try this on the laptop tomorrow, time for bed now. On
this machine I have Visual Studio 2008 beta 2.
Michael
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 4:33 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
> IronPython 2 Import Mechanism
>
> Dino Viehland wrote:
>
>> Are you running on a beta of Orcas? It could be an Orcas bug.
>>
>>
> I have the Orcas beta installed (which I guess means yes).
>
> I don't have it on my laptop - I can try with that.
>
> Michael
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
>> Sent: Friday, November 02, 2007 4:12 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
>> IronPython 2 Import Mechanism
>>
>> I'm not sure what's going on here - I've pinged the CLR dev who owns this
>> feature. In some patches (at some point) post v2.0.50727.42 there were some
>> changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks
>> like it could be a regression related to those changes. But I don't
>> understand the big picture here.
>>
>> As a work around you might be able to run in -X:GenerateAsSnippets mode. In
>> v2.0 this results in about a 10% perf degrade (last time I measured at
>> least, and this was against Pystone) but stops us from generating types to
>> create modules. So ultimately we won't create an assembly and won't go down
>> this code path. Of course, that may just be putting off the inevitable.
>>
>> Another possiblity might be grepping Python.NET to see if they're doing
>> anything weird w/ Module or Assembly objects, although I wouldn't know
>> exactly what to look for.
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
>> Sent: Friday, November 02, 2007 3:33 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
>> IronPython 2 Import Mechanism
>>
>> You asked for it. :-)
>>
>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>> Copyright (c) Microsoft Corporation. All rights reserved.
>> >>> import clr
>> >>> clr.AddReference('Python.Runtime')
>> >>> from Python.Runtime import PythonEngine
>> >>> engine = PythonEngine()
>> >>> engine.Initialize()
>> >>> import xyzz
>> Unable to cast object of type 'System.Reflection.Module' to type
>> 'System.Reflect
>> ion.Emit.ModuleBuilder'.
>>at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
>>at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
>> Assembly
>> BuilderAccess access, String dir, Evidence evidence, PermissionSet
>> requiredPermi
>> ssions, PermissionSet optionalPermissions, PermissionSet
>> refusedPermissions, Sta
>> ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
>>at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
>> AssemblyBuilderA
>> ccess access)
>>at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
>> moduleName, String
>> outDir, String outFile, AssemblyGenAttributes generationAttributes,
>> PortableExe
>> cutableKinds peKind, ImageFileMachine machine)
>>at
>> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
>> mbly(ScriptCode scriptCode)
>>at
>> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
>> y(ScriptCode scriptCode)
>>at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
>> ator(ScriptCode scriptCode)
>>at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
>> ods()
>>at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
>>at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
>> ScriptMo
>> duleKind kind, Scope scope, ScriptCode[] scriptCodes)
>>at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
>> ScriptM
>> oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
>> errorSink, Sourc
>> eUnit[] sourceUnits)
>>at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
>> SourceU
>> nit sourceUnit)
>>at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
>> context, Stri
>> ng name, String path)
>>at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
>> String nam
>> e, String fullName, List path)
>>at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
>> String
>> name)
>>at IronPython.Runtime.Importer.ImportModule(CodeContext context,
>> String modNa
>> me, Boolean bottom)
>>at IronPython.Runtime.Builtin.__import__(CodeContex
[IronPython] __getattribute__ bug
Hello all,
A bug in '__getattribute__' - magic methods should be fetched from the
class and not go through '__getattribute__'.
This is making a proxy class I'm writing behave very oddly:
The following code:
def DoNothing(*args):
pass
class Something(object):
def __getattribute__(self, name):
print name
return DoNothing
def __call__(self):
print 'called'
def __getitem__(self, name):
raise Exception('w00t!')
def __setitem__(self, name, value):
raise Exception('w00t!')
s = Something()
s['fish'] = 3
Does this on CPython:
C:\compile\cext\trunk\cext>descriptors.py
Traceback (most recent call last):
File "C:\compile\cext\trunk\cext\descriptors.py", line 20, in ?
s['fish'] = 3
File "C:\compile\cext\trunk\cext\descriptors.py", line 17, in __setitem__
raise Exception('w00t!')
Exception: w00t!
And this on IronPython 2a5:
C:\compile\cext\trunk\cext>C:\compile\IronPython2\ipy.exe -D
-X:TabCompletion -X
:ColorfulConsole descriptors.py
__setitem__
To make things odder - if the class 'Something' doesn't have a
__setitem__ method then an attribute error is correctly raised. For
'__call__' I am *sometimes* seeing that go through '__getattribute__'
and sometimes not...
Michael
http://www.manning.com/foord
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
Cool, I suspect it'll work fine on your laptop. Do you have Orcas beta 2
installed or something else?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 4:33 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
IronPython 2 Import Mechanism
Dino Viehland wrote:
> Are you running on a beta of Orcas? It could be an Orcas bug.
>
I have the Orcas beta installed (which I guess means yes).
I don't have it on my laptop - I can try with that.
Michael
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
> Sent: Friday, November 02, 2007 4:12 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
> IronPython 2 Import Mechanism
>
> I'm not sure what's going on here - I've pinged the CLR dev who owns this
> feature. In some patches (at some point) post v2.0.50727.42 there were some
> changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like
> it could be a regression related to those changes. But I don't understand
> the big picture here.
>
> As a work around you might be able to run in -X:GenerateAsSnippets mode. In
> v2.0 this results in about a 10% perf degrade (last time I measured at least,
> and this was against Pystone) but stops us from generating types to create
> modules. So ultimately we won't create an assembly and won't go down this
> code path. Of course, that may just be putting off the inevitable.
>
> Another possiblity might be grepping Python.NET to see if they're doing
> anything weird w/ Module or Assembly objects, although I wouldn't know
> exactly what to look for.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:33 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
> IronPython 2 Import Mechanism
>
> You asked for it. :-)
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference('Python.Runtime')
> >>> from Python.Runtime import PythonEngine
> >>> engine = PythonEngine()
> >>> engine.Initialize()
> >>> import xyzz
> Unable to cast object of type 'System.Reflection.Module' to type
> 'System.Reflect
> ion.Emit.ModuleBuilder'.
>at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
>at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
> Assembly
> BuilderAccess access, String dir, Evidence evidence, PermissionSet
> requiredPermi
> ssions, PermissionSet optionalPermissions, PermissionSet
> refusedPermissions, Sta
> ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
>at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
> AssemblyBuilderA
> ccess access)
>at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
> moduleName, String
> outDir, String outFile, AssemblyGenAttributes generationAttributes,
> PortableExe
> cutableKinds peKind, ImageFileMachine machine)
>at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
> mbly(ScriptCode scriptCode)
>at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
> y(ScriptCode scriptCode)
>at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
> ator(ScriptCode scriptCode)
>at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
> ods()
>at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
>at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
> ScriptMo
> duleKind kind, Scope scope, ScriptCode[] scriptCodes)
>at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> ScriptM
> oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
> errorSink, Sourc
> eUnit[] sourceUnits)
>at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> SourceU
> nit sourceUnit)
>at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
> context, Stri
> ng name, String path)
>at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
> String nam
> e, String fullName, List path)
>at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
> String
> name)
>at IronPython.Runtime.Importer.ImportModule(CodeContext context,
> String modNa
> me, Boolean bottom)
>at IronPython.Runtime.Builtin.__import__(CodeContext context, String
> name, Ob
> ject globals, Object locals, Object fromList)
>at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
> , IAttr
> ibutesCollection , IAttributesCollection , PythonTuple )
>at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
> context
Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
Dino Viehland wrote:
> Are you running on a beta of Orcas? It could be an Orcas bug.
>
I have the Orcas beta installed (which I guess means yes).
I don't have it on my laptop - I can try with that.
Michael
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
> Sent: Friday, November 02, 2007 4:12 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
> IronPython 2 Import Mechanism
>
> I'm not sure what's going on here - I've pinged the CLR dev who owns this
> feature. In some patches (at some point) post v2.0.50727.42 there were some
> changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like
> it could be a regression related to those changes. But I don't understand
> the big picture here.
>
> As a work around you might be able to run in -X:GenerateAsSnippets mode. In
> v2.0 this results in about a 10% perf degrade (last time I measured at least,
> and this was against Pystone) but stops us from generating types to create
> modules. So ultimately we won't create an assembly and won't go down this
> code path. Of course, that may just be putting off the inevitable.
>
> Another possiblity might be grepping Python.NET to see if they're doing
> anything weird w/ Module or Assembly objects, although I wouldn't know
> exactly what to look for.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:33 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
> IronPython 2 Import Mechanism
>
> You asked for it. :-)
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference('Python.Runtime')
> >>> from Python.Runtime import PythonEngine
> >>> engine = PythonEngine()
> >>> engine.Initialize()
> >>> import xyzz
> Unable to cast object of type 'System.Reflection.Module' to type
> 'System.Reflect
> ion.Emit.ModuleBuilder'.
>at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
>at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
> Assembly
> BuilderAccess access, String dir, Evidence evidence, PermissionSet
> requiredPermi
> ssions, PermissionSet optionalPermissions, PermissionSet
> refusedPermissions, Sta
> ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
>at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
> AssemblyBuilderA
> ccess access)
>at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
> moduleName, String
> outDir, String outFile, AssemblyGenAttributes generationAttributes,
> PortableExe
> cutableKinds peKind, ImageFileMachine machine)
>at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
> mbly(ScriptCode scriptCode)
>at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
> y(ScriptCode scriptCode)
>at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
> ator(ScriptCode scriptCode)
>at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
> ods()
>at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
>at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
> ScriptMo
> duleKind kind, Scope scope, ScriptCode[] scriptCodes)
>at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> ScriptM
> oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
> errorSink, Sourc
> eUnit[] sourceUnits)
>at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> SourceU
> nit sourceUnit)
>at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
> context, Stri
> ng name, String path)
>at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
> String nam
> e, String fullName, List path)
>at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
> String
> name)
>at IronPython.Runtime.Importer.ImportModule(CodeContext context,
> String modNa
> me, Boolean bottom)
>at IronPython.Runtime.Builtin.__import__(CodeContext context, String
> name, Ob
> ject globals, Object locals, Object fromList)
>at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
> , IAttr
> ibutesCollection , IAttributesCollection , PythonTuple )
>at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
> context, T0 a
> rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
>at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
> context, Str
> ing fullName)
>at ##18(Object[] , CodeContext )
>at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
> Boolean tryEva
> luate)
>at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>at Microsoft.Scripting.Hosti
Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
Are you running on a beta of Orcas? It could be an Orcas bug.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Friday, November 02, 2007 4:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
IronPython 2 Import Mechanism
I'm not sure what's going on here - I've pinged the CLR dev who owns this
feature. In some patches (at some point) post v2.0.50727.42 there were some
changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like
it could be a regression related to those changes. But I don't understand the
big picture here.
As a work around you might be able to run in -X:GenerateAsSnippets mode. In
v2.0 this results in about a 10% perf degrade (last time I measured at least,
and this was against Pystone) but stops us from generating types to create
modules. So ultimately we won't create an assembly and won't go down this code
path. Of course, that may just be putting off the inevitable.
Another possiblity might be grepping Python.NET to see if they're doing
anything weird w/ Module or Assembly objects, although I wouldn't know exactly
what to look for.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 3:33 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
IronPython 2 Import Mechanism
You asked for it. :-)
IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Python.Runtime')
>>> from Python.Runtime import PythonEngine
>>> engine = PythonEngine()
>>> engine.Initialize()
>>> import xyzz
Unable to cast object of type 'System.Reflection.Module' to type
'System.Reflect
ion.Emit.ModuleBuilder'.
at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
Assembly
BuilderAccess access, String dir, Evidence evidence, PermissionSet
requiredPermi
ssions, PermissionSet optionalPermissions, PermissionSet
refusedPermissions, Sta
ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
AssemblyBuilderA
ccess access)
at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
moduleName, String
outDir, String outFile, AssemblyGenAttributes generationAttributes,
PortableExe
cutableKinds peKind, ImageFileMachine machine)
at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
mbly(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
y(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
ator(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
ods()
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
ScriptMo
duleKind kind, Scope scope, ScriptCode[] scriptCodes)
at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
ScriptM
oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
errorSink, Sourc
eUnit[] sourceUnits)
at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
SourceU
nit sourceUnit)
at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, Stri
ng name, String path)
at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
String nam
e, String fullName, List path)
at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
String
name)
at IronPython.Runtime.Importer.ImportModule(CodeContext context,
String modNa
me, Boolean bottom)
at IronPython.Runtime.Builtin.__import__(CodeContext context, String
name, Ob
ject globals, Object locals, Object fromList)
at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
, IAttr
ibutesCollection , IAttributesCollection , PythonTuple )
at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
context, T0 a
rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
context, Str
ing fullName)
at ##18(Object[] , CodeContext )
at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
Boolean tryEva
luate)
at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
module)
at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
code, IScri
ptModule module)
at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
at Microsoft.Scripting.She
Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
I'm not sure what's going on here - I've pinged the CLR dev who owns this
feature. In some patches (at some point) post v2.0.50727.42 there were some
changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like
it could be a regression related to those changes. But I don't understand the
big picture here.
As a work around you might be able to run in -X:GenerateAsSnippets mode. In
v2.0 this results in about a 10% perf degrade (last time I measured at least,
and this was against Pystone) but stops us from generating types to create
modules. So ultimately we won't create an assembly and won't go down this code
path. Of course, that may just be putting off the inevitable.
Another possiblity might be grepping Python.NET to see if they're doing
anything weird w/ Module or Assembly objects, although I wouldn't know exactly
what to look for.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 3:33 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the
IronPython 2 Import Mechanism
You asked for it. :-)
IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Python.Runtime')
>>> from Python.Runtime import PythonEngine
>>> engine = PythonEngine()
>>> engine.Initialize()
>>> import xyzz
Unable to cast object of type 'System.Reflection.Module' to type
'System.Reflect
ion.Emit.ModuleBuilder'.
at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
Assembly
BuilderAccess access, String dir, Evidence evidence, PermissionSet
requiredPermi
ssions, PermissionSet optionalPermissions, PermissionSet
refusedPermissions, Sta
ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
AssemblyBuilderA
ccess access)
at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
moduleName, String
outDir, String outFile, AssemblyGenAttributes generationAttributes,
PortableExe
cutableKinds peKind, ImageFileMachine machine)
at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
mbly(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
y(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
ator(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
ods()
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
ScriptMo
duleKind kind, Scope scope, ScriptCode[] scriptCodes)
at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
ScriptM
oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
errorSink, Sourc
eUnit[] sourceUnits)
at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
SourceU
nit sourceUnit)
at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, Stri
ng name, String path)
at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
String nam
e, String fullName, List path)
at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
String
name)
at IronPython.Runtime.Importer.ImportModule(CodeContext context,
String modNa
me, Boolean bottom)
at IronPython.Runtime.Builtin.__import__(CodeContext context, String
name, Ob
ject globals, Object locals, Object fromList)
at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
, IAttr
ibutesCollection , IAttributesCollection , PythonTuple )
at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
context, T0 a
rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
context, Str
ing fullName)
at ##18(Object[] , CodeContext )
at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
Boolean tryEva
luate)
at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
module)
at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
code, IScri
ptModule module)
at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
TypeError: Unable to cast object of type 'System.Reflection.Module' to
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.
>>>
Dino Viehland wrote:
> Could you run with -X:ExceptionDetail and report back the stack trace?
> That'll let us know where the exception is actually coming from.
>
> -Original
Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
You asked for it. :-)
IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Python.Runtime')
>>> from Python.Runtime import PythonEngine
>>> engine = PythonEngine()
>>> engine.Initialize()
>>> import xyzz
Unable to cast object of type 'System.Reflection.Module' to type
'System.Reflect
ion.Emit.ModuleBuilder'.
at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
Assembly
BuilderAccess access, String dir, Evidence evidence, PermissionSet
requiredPermi
ssions, PermissionSet optionalPermissions, PermissionSet
refusedPermissions, Sta
ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
AssemblyBuilderA
ccess access)
at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
moduleName, String
outDir, String outFile, AssemblyGenAttributes generationAttributes,
PortableExe
cutableKinds peKind, ImageFileMachine machine)
at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
mbly(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
y(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
ator(ScriptCode scriptCode)
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
ods()
at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
ScriptMo
duleKind kind, Scope scope, ScriptCode[] scriptCodes)
at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
ScriptM
oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
errorSink, Sourc
eUnit[] sourceUnits)
at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
SourceU
nit sourceUnit)
at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, Stri
ng name, String path)
at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
String nam
e, String fullName, List path)
at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
String
name)
at IronPython.Runtime.Importer.ImportModule(CodeContext context,
String modNa
me, Boolean bottom)
at IronPython.Runtime.Builtin.__import__(CodeContext context, String
name, Ob
ject globals, Object locals, Object fromList)
at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
, IAttr
ibutesCollection , IAttributesCollection , PythonTuple )
at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
context, T0 a
rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
context, Str
ing fullName)
at ##18(Object[] , CodeContext )
at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
Boolean tryEva
luate)
at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
module)
at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
code, IScri
ptModule module)
at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
TypeError: Unable to cast object of type 'System.Reflection.Module' to
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.
>>>
Dino Viehland wrote:
> Could you run with -X:ExceptionDetail and report back the stack trace?
> That'll let us know where the exception is actually coming from.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:25 PM
> To: Discussion of IronPython
> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import
> Mechanism
>
> Hello Guys,
>
> Not sure what is going on here, nor whether it indicates a bug in
> IronPython, but it is certainly odd. Loading a CPython interpreter
> through the Python.NET assembly seems to change the IronPython (2a5)
> import machinery.
>
> I have a test module 'xyzz.py' that has an unused name 'wibble'.
> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
> name error:
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import xyzz
> Traceback (most recent call last):
> File , line 0, in ##7
> File , line 0, in _stub_##2
> File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
> NameError: name 'wibble' is not defined
>
>
> Executing the following code, (using the 'Python.Runtime' assembly from
> Python.NET with Python 2.4):
Re: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
Could you run with -X:ExceptionDetail and report back the stack trace? That'll
let us know where the exception is actually coming from.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 3:25 PM
To: Discussion of IronPython
Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import
Mechanism
Hello Guys,
Not sure what is going on here, nor whether it indicates a bug in
IronPython, but it is certainly odd. Loading a CPython interpreter
through the Python.NET assembly seems to change the IronPython (2a5)
import machinery.
I have a test module 'xyzz.py' that has an unused name 'wibble'.
Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
name error:
IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import xyzz
Traceback (most recent call last):
File , line 0, in ##7
File , line 0, in _stub_##2
File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
NameError: name 'wibble' is not defined
Executing the following code, (using the 'Python.Runtime' assembly from
Python.NET with Python 2.4):
IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Python.Runtime')
>>>
>>> from Python.Runtime import PythonEngine
>>> engine = PythonEngine()
>>> engine.Initialize()
>>>
>>> import xyzz
Traceback (most recent call last):
File , line 0, in ##18
File , line 0, in _stub_##2
File mscorlib, line unknown, in DefineDynamicAssembly
File mscorlib, line unknown, in InternalDefineDynamicAssembly
TypeError: Unable to cast object of type 'System.Reflection.Module' to
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.
Just importing the 'PythonEngine' isn't enough. The problem only happens
if the PythonEngine is instantiated and initialized.
All the best,
Michael
___
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] Embedding CPython Messes with the IronPython 2 Import Mechanism
Hello Guys,
Not sure what is going on here, nor whether it indicates a bug in
IronPython, but it is certainly odd. Loading a CPython interpreter
through the Python.NET assembly seems to change the IronPython (2a5)
import machinery.
I have a test module 'xyzz.py' that has an unused name 'wibble'.
Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
name error:
IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import xyzz
Traceback (most recent call last):
File , line 0, in ##7
File , line 0, in _stub_##2
File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
NameError: name 'wibble' is not defined
Executing the following code, (using the 'Python.Runtime' assembly from
Python.NET with Python 2.4):
IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Python.Runtime')
>>>
>>> from Python.Runtime import PythonEngine
>>> engine = PythonEngine()
>>> engine.Initialize()
>>>
>>> import xyzz
Traceback (most recent call last):
File , line 0, in ##18
File , line 0, in _stub_##2
File mscorlib, line unknown, in DefineDynamicAssembly
File mscorlib, line unknown, in InternalDefineDynamicAssembly
TypeError: Unable to cast object of type 'System.Reflection.Module' to
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.
Just importing the 'PythonEngine' isn't enough. The problem only happens
if the PythonEngine is instantiated and initialized.
All the best,
Michael
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Importing package with imp
Thanks for the report! It looks like we're just passing the wrong name to
Importer.InitializeModule (initPath instead of moduleName). I'll check-in a
fix and update test_imp_package() to check sys.modules.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Thursday, November 01, 2007 10:50 PM
To: Discussion of IronPython
Subject: [IronPython] Importing package with imp
Importing package with imp module is tested in test_imp_package()
function of test_imp.py. But sys.modules is incorrectly modified by
imp which this test misses...
Okay, if I was not working on some obscure importing hack, I guess no
one would have found this. :(
How to reproduce:
# x/__init__.py
a = 1
# test.py
import imp
imp.load_module('x', None, 'x', ('', '', imp.PKG_DIRECTORY))
import sys
print sys.modules['x'].a
--
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] setattr and module
Thanks for the report Seo, I'll fix this for a future release (I don't think it'll make it in time for the next one). The problem here is that we're not currently using DynamicSite's for the setattr built-in function. Instead we go to a runtime call in PythonOps which is going to attempt to do this via interfaces and DynamicType's. That's actually not the correct way to set attributes anymore as it doesn't work x-lang (or w/ the member access operators that are defined on ScriptModule). Luckily get/delete were switched over a while ago so those just work. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Friday, November 02, 2007 7:57 AM To: Discussion of IronPython Subject: [IronPython] setattr and module # x.py # empty # test.py import x setattr(x, 'a', 1) print x.a AttributeError: 'module' object has no attribute 'a' -- 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] setattr and module
# x.py # empty # test.py import x setattr(x, 'a', 1) print x.a AttributeError: 'module' object has no attribute 'a' -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] i thought this is odd: using Interop on Microsoft Word
This could be fixed in IronPython but currently its expected.
docs[1] is calling into this indexer in Microsoft.Office.Interop.Word.dll. The
indexer method takes the index by-reference. Ie as "object&" instead of just
"object".
.method instance class Microsoft.Office.Interop.Word.Document
get_Item([in] object& marshal( struct) Index)
{
} // end of method Documents::get_Item
IronPython thinks that is a ref parameter that could potentially by updated by
the call. Hence, it returns it back as one of the return values.
>>> returnValues = docs[1]
>>> returnValues[0] # real return value
Microsoft.Office.Interop.Word.DocumentClass
>>> returnValues[1] # the by-ref param included in the return value.
1
>>>
In C#, you would have to use the "ref" keyword to index into docs. You can
simulate this in IronPython as such
>>> docs[clr.Reference[object](1)]
Microsoft.Office.Interop.Word.DocumentClass
>>>
IronPython could fix this by paying attention to the "[in]" in the signature.
It appears as a custom attribute of type
System.Runtime.InteropServices.InAttribute on the parameter. I have opened
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13641 to track
this.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelie
Sent: Friday, November 02, 2007 12:45 AM
To: IronPython Users
Subject: [IronPython] i thought this is odd: using Interop on Microsoft Word
Hello group,
import clr
clr.AddReference("Microsoft.Office.Interop.Word")
import Microsoft.Office.Interop.Word as Word
_progid_ = "Word.Application"
def get_active_object(progid):
from System.Runtime.InteropServices import Marshal
try:
app = Marshal.GetActiveObject(progid)
except:
app = None
return app
def get_active_application():
return get_active_object(_progid_)
def get_documents():
return get_active_application().Documents
if __name__ == '__main__':
docs = get_documents()
#print docs[1].FullName # This line causes AttributeError:
# 'tuple' object has no attribute 'FullName'
print docs[1] # returns (Microsoft.Office.Interop.Word.DocumentClass, 1)
print docs[2] # returns (Microsoft.Office.Interop.Word.DocumentClass, 2)
print docs[1][0].FullName
This is the code that i tested. For the last couple of lines, i was
expecting that
docs[1] and docs[2] would return the document object instead of a
tuple with the first of its item being the document. Is this the
intended behavior?
Thank you,
--
Kelie
___
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
