[IronPython] "TypeError: Microsoft.Scripting.DynamicType is not callable" bug(?)

[Dino Viehland]

I could be asking the obvious but do square brackets work for you?

I would expect:

result=win32com.client.Dispatch("COMClass")["ItemName"]
result=win32com.client.Dispatch("COMClass")[0]

to work or possibly:

result=win32com.client.Dispatch("COMClass").Item[0]

Another possibility is selecting the overloads on get_Item.  I don't know why we'd think there'd be two object versions but bound methods will have an "Overloads" property (after importing clr or another .NET namespace) which might help you (I'm not sure it will, but it's worth a shot).

Finally I would suggest that you could also look into making a PIA (Primary Interop Assembly) for your COM objects if you have a TLB instead of writing your own dispatch code.  A tool ships w/ the .NET framework called tlbimp so if you have a TLB for your COM objects you can use that to generate an assembly.  Add a reference to that assembly and you might find that you have a better COM experience.  Unfortunately that only helps if you have a TLB available.

Hopefully one of those will help.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Martin
Sent: Wednesday, July 11, 2007 7:45 AM
To: users at lists.ironpython.com
Subject: [IronPython] "TypeError: Microsoft.Scripting.DynamicType is not callable" bug(?)

Hi,

Background:
We have a number of Python scripts that we use for updating and setting up the devices my company make. We do this through calls to a number of COM classes via win32com.client.Dispatch().

We are interested in being able to call these Python scripts from various .NET GUI applications written in C# so naturally I started looking into IronPython.

My goal is to make our CPython code as executable in IronPython as humanly possible so since win32com is not available through IronPython I wrote a simple C# interop wrapper handling the interops for the specific COM classes we need to call when setting up our devices:

namespace win32com
{
      public class client
      {
             public static object Dispatch(string comName)
             {
                  <rip>
             }
      }
}

The annoying thing is that this "hack" works like a charm except in one type of case.

Problem:
Some of our COM classes return Item collections that are indexable by both specific names (string indexing) and normal int indexes
- example in CPython: result=win32com.client.Dispatch("COMClass")("ItemName") and/or result=win32com.client.Dispatch("COMClass")(0)

This works like a charm in CPython (and the interop version of our C# code for that matter) but it does NOT work in IronPython.
In IronPython 1.1 I get this error message "TypeError: object is not callable"
In IronPython 2.0 alpha 3 I get this error message: "TypeError: Microsoft.Scripting.DynamicType is not callable".

I can access the properties of the object such as item count however I cannot index into the result object by calling result.get_Item("ItemName"). It gives the following error message

TypeError: multiple overloads of get_Item could match (String)
  get_Item(Object)
  get_Item(Object)

nor can I index into the result object by calling result.get_Item(0) which gives a similar error except the problematic match is Int32.

So apparently IronPython cannot identify the type of the index objects when more are present?

Question

Anyone have any comments that can help me here? Have I missed some subtle issues with COM interop? Is this a known bug and if so when do you think it will be fixed?

(I know I can get around the problem by writing specific IronPython code + changing the handling of the COM class in my C# wrapper but I REALLY don't want to nor should I have to if the goal is to make IronPython as clean as possible port of CPython.)

PS.
Great initiative and great work otherwise in the port

BR
Martin Storm Møller

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070711/ef719bc3/attachment.html>