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

Martin storm.openmail at gmail.com
Thu Jul 12 11:11:54 CEST 2007


You are asking the obvious... or rather it *should* have been obvious. But
unfortunately it wasn't...

Yes,

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

works.

As for your final suggestion (which is excellent). We do have a TLB and I
have already fooled around with a tlbimp generated interop dll. However it
doesn't help in respect to making it possible to run our CPython scripts in
IronPython. Something that is not simple to accomplish when COM interop
rears it's ugly head.

Thank you very much for the quick reply - even though it made me want to
bang my head into the table ;-)

BR
Martin


On 7/11/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>
>  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
>
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070712/d8b52615/attachment.html>


More information about the Ironpython-users mailing list