Re: [comtypes-users] dyndispatch branch
Hi Thomas, The new changes to the dyndispatch branch sound great. I'm definitely still interested in the branch, and am hoping that once its stable enough that it can be merged in to trunk so I can start using it properly in the NVDA project. I havn't fully tested out all the changes you mentioned yet, but from what you have written, they all sound ok to me. I'm also glad you decided against any early binding, as they really would have limited performance, specially if the user was not going to use a lot of the methods on a particular interface. One thing: comtypes.client.lazybind.NamedProperty. You ask in the comments whether or not to support __call__. I would definitely say yes, but I don't quite understand what you are doing with __getitem__. I assume that NamedProperties in COM can have more than one optional argument, and if this os so, then calling would be the only way to pass more than one argument. From what I can see, at the moment we're supposed to do something like bla.accName[0] rather than bla.accName(0)? Also, what happens if you want to not provide the optional argument at all? Obviously in python you can't write bla.accName[], but with __call__ you could at least do bla.accName() Perhaps I don't quite follow what your __getitem__ etc is doing. Would you be able to provide me with an explination on this? Thanks again Mick On 25/10/2008 5:09 AM, Thomas Heller wrote: > Thomas Heller schrieb: >> Michael Curran schrieb: >>> Hi, >>> >>> After testing with the dyndispatch svn branch of comtypes, I relised >>> that there is a problem with dynamic Dispatch and IEnumVARIANT being >>> used together. >>> >>> The problem is that If you enumerate a dynamic dispatch object (you get >>> an IEnumVARIANT object some how from it), that IEnumVARIANT object >>> doesn't know it has to provide dynamic=True to variant._get_value. So, >>> the IEnumVARIANT's next method returns objects with fully generated >>> interfaces, rather than just dynamic dispatch support. >>> >>> I would suggest that comtypes.automation.IEnumVARIANT have an instance >>> variable called dynamic, which can be set to False by default. But if >>> true, then the Next method should provide dynamic=True when getting >>> variants. > > This suggestion is now implemented. > > Here is the current state of the dyndispatch branch (in case Michael or > someone > else still cares about this stuff, which I hope!): > > The comtypes.client.CreateObject() function accepts an optional keyword > argument 'dynamic' that defaults to False. The behaviour of the function is > unchanged if 'dynamic=False', comtypes tries to generate and then imports the > wrapper code for the object it creates. > > When CreateObject(..., dynamic=True) is called then no wrapper code is > generated (well, if the object supports the IDispatch interface). > > If the com object exposes NO type information, then, as before, an instance > of comtypes.client.dynamic._Dispatch is returned supporting method calls and > property > access by pure dynamic dispatch calls (GetIDsOfNames, and Invoke calls). > > If the com object exposes type information (and supports the ITypeComp > interface), > then an instance of the new module comtypes.client.lazybind.Dispatch is > returned. > Methods and properties are then bound by name, using ITypeComp.Bind() calls. > > Distributing the code for dynamic dispatch with or without type info over two > different > modules make the code a lot cleaner. > >> 3. Calling IDispatch.Invoke(...) is currently fairly slow. This is >> because packing the arguments into the DISPPARAMS instance with ctypes >> is very slow. This can probably be made a lot faster with a compiled >> comtypes extension module. Also, the signature of IDispatch.Invoke() >> in comtypes is wrong, it was a mistake to pass the invkind flags only >> as keyword dictionary (and I thought it was clever!). > > This remains, but can be solved later if it turns out that it is really > a problem. I would very much like to keep comtypes without any extension > module, pure python. > >> 4. After playing around a little, I have the impression that it may be >> better to create a separate subclass of a _Dispatch base class for >> each COM object, and to generate the methods and properties in the >> __init__ method from typeinfo. The big advantage is that the >> resulting class has all methods (with parameter names!) and >> properties that are available in the COM object, so code completion, >> inspection, and so on will work. > > This I did not implement, it sounds much like early binding with all its > problems that we want to get rid of. The dynamic dispatch code does > everything > on demand only (although I tried to cache the results of expensive calls to > ITypeComp). > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Mobli
Re: [comtypes-users] dyndispatch branch
Michael Curran schrieb: > Hi Thomas, > > The new changes to the dyndispatch branch sound great. > > I'm definitely still interested in the branch, and am hoping that once > its stable enough that it can be merged in to trunk so I can start using > it properly in the NVDA project. > > I havn't fully tested out all the changes you mentioned yet, but from > what you have written, they all sound ok to me. I'm also glad you > decided against any early binding, as they really would have limited > performance, specially if the user was not going to use a lot of the > methods on a particular interface. > > One thing: comtypes.client.lazybind.NamedProperty. You ask in the > comments whether or not to support __call__. I would definitely say yes, > but I don't quite understand what you are doing with __getitem__. > > I assume that NamedProperties in COM can have more than one optional > argument, and if this os so, then calling would be the only way to pass > more than one argument. From what I can see, at the moment we're > supposed to do something like bla.accName[0] rather than bla.accName(0)? > Also, what happens if you want to not provide the optional argument at all? > Obviously in python you can't write bla.accName[], but with __call__ you > could at least do bla.accName() The idea was to use always use [...] notation for property accesses with arguments (what I call NamedProperties). This is because of the symmetry between getting and setting: print foo[a, b, c] foo[a, b, c] = something Normal properties (not taking arguments) are accessed in the usual way: print foo.attr foo.attr = something Ok, so the problem occurs when accessing a property which takes optional arguments, and you don't want to pass any. Obviously 'foo.attr()' does work, but how to set it - 'foo.attr() = something' is invalid syntax, but 'foo.attr[] = something' and 'print foo.attr[]' are invalid as well. AFAIK pywin32 solves that by creating separate setter functions like 'foo._setattr(something)' but I don't like this. So I decided to do it differently in comtypes (the approach I describe here is already implemented for the usual early bound COM calls, but not yet for the comtypes.client.lazybind or comtypes.client.dynamic module): Python lets you call __getitem__(self, index) with any number of arguments, although the syntax is a little bit strange first. It becomes clearer when you think of the signature __getitem__(self, *args). Here is an interactive session; it shows that you can call x[...] with more one or more arguments: >>> class X(object): ... def __getitem__(self, *args): ... print "__getitem__", args ... def __setitem__(self, *args): ... print "__setitem__", args ... >>> x = X() >>> >>> x[()] __getitem__ ((),) >>> x[1] __getitem__ (1,) >>> x[1, 2] __getitem__ ((1, 2),) >>> x[1, 2, 3] __getitem__ ((1, 2, 3),) >>> The strange thing is that calling 'x[()]' behaves in the same way as the hypothetical call 'x[]' had been made. BTW: the same holds for __setitem__(self, *args): >>> x[()] = 42 __setitem__ ((), 42) >>> x[1] = 42 __setitem__ (1, 42) >>> x[1, 2] = 42 __setitem__ ((1, 2), 42) >>> x[1, 2, 3] = 42 __setitem__ ((1, 2, 3), 42) >>> >>> >>> x[()] = 42 __setitem__ ((), 42) >>> x[1] = 42 __setitem__ (1, 42) >>> x[1, 2] = 42 __setitem__ ((1, 2), 42) >>> x[1, 2, 3] = 42 __setitem__ ((1, 2, 3), 42) >>> >>> One obvious fault of the above is that it is impossible to access properties with named arguments (but comtypes.client.dynamic and comtypes.client.lazybind does not accept named arguments anyway in methods currently). Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
Re: [comtypes-users] dyndispatch branch
Hi, Thanks for the explanation. If comtypes is already using the [] syntax for early bound interfaces, and if that is the most suitable way, then that sounds ok to me. I agree that it is important to keep dyn dispatch interfaces as compatible with early bound interfaces as possible. So, I also in that case do also think that __call__ should be implemented. In order so that named properties with optional or needed arguments can be called with () for getting, even though you could also use the [] syntax as well. In our projects, and I suspect others, comtypes early bound propgets with arguments are called with (), I never new about []. Mick On 28/10/2008 6:06 AM, Thomas Heller wrote: > Michael Curran schrieb: >> Hi Thomas, >> >> The new changes to the dyndispatch branch sound great. >> >> I'm definitely still interested in the branch, and am hoping that once >> its stable enough that it can be merged in to trunk so I can start using >> it properly in the NVDA project. >> >> I havn't fully tested out all the changes you mentioned yet, but from >> what you have written, they all sound ok to me. I'm also glad you >> decided against any early binding, as they really would have limited >> performance, specially if the user was not going to use a lot of the >> methods on a particular interface. >> >> One thing: comtypes.client.lazybind.NamedProperty. You ask in the >> comments whether or not to support __call__. I would definitely say yes, >> but I don't quite understand what you are doing with __getitem__. >> >> I assume that NamedProperties in COM can have more than one optional >> argument, and if this os so, then calling would be the only way to pass >> more than one argument. From what I can see, at the moment we're >> supposed to do something like bla.accName[0] rather than bla.accName(0)? >> Also, what happens if you want to not provide the optional argument at all? >> Obviously in python you can't write bla.accName[], but with __call__ you >> could at least do bla.accName() > > The idea was to use always use [...] notation for property accesses with > arguments > (what I call NamedProperties). This is because of the symmetry between > getting and setting: > > print foo[a, b, c] > foo[a, b, c] = something > > Normal properties (not taking arguments) are accessed in the usual way: > > print foo.attr > foo.attr = something > > Ok, so the problem occurs when accessing a property which takes optional > arguments, and you don't want to pass any. Obviously 'foo.attr()' does work, > but how to set it - 'foo.attr() = something' is invalid syntax, > but 'foo.attr[] = something' and 'print foo.attr[]' are invalid as well. > > AFAIK pywin32 solves that by creating separate setter functions like > 'foo._setattr(something)' but I don't like this. > > So I decided to do it differently in comtypes (the approach I describe here > is already implemented for the usual early bound COM calls, but not yet for > the comtypes.client.lazybind or comtypes.client.dynamic module): > > Python lets you call __getitem__(self, index) with any number of arguments, > although the syntax is a little bit strange first. It becomes clearer when > you think of the signature __getitem__(self, *args). Here is an interactive > session; it shows that you can call x[...] with more one or more arguments: > class X(object): > ... def __getitem__(self, *args): > ... print "__getitem__", args > ... def __setitem__(self, *args): > ... print "__setitem__", args > ... x = X() x[()] > __getitem__ ((),) x[1] > __getitem__ (1,) x[1, 2] > __getitem__ ((1, 2),) x[1, 2, 3] > __getitem__ ((1, 2, 3),) > > The strange thing is that calling 'x[()]' behaves in the same way as the > hypothetical call 'x[]' had been made. > BTW: the same holds for __setitem__(self, *args): > x[()] = 42 > __setitem__ ((), 42) x[1] = 42 > __setitem__ (1, 42) x[1, 2] = 42 > __setitem__ ((1, 2), 42) x[1, 2, 3] = 42 > __setitem__ ((1, 2, 3), 42) > x[()] = 42 > __setitem__ ((), 42) x[1] = 42 > __setitem__ (1, 42) x[1, 2] = 42 > __setitem__ ((1, 2), 42) x[1, 2, 3] = 42 > __setitem__ ((1, 2, 3), 42) > > One obvious fault of the above is that it is impossible to access properties > with named arguments (but comtypes.client.dynamic and comtypes.client.lazybind > does not accept named arguments anyway in methods currently). > > Thomas > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK& win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > comtypes-users mailing list > comtypes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/co
Re: [comtypes-users] dyndispatch branch
Michael Curran schrieb: > Hi, > > Thanks for the explanation. If comtypes is already using the [] syntax > for early bound interfaces, and if that is the most suitable way, then > that sounds ok to me. I agree that it is important to keep dyn dispatch > interfaces as compatible with early bound interfaces as possible. > > So, I also in that case do also think that __call__ should be > implemented. In order so that named properties with optional or needed > arguments can be called with () for getting, even though you could also > use the [] syntax as well. > In our projects, and I suspect others, comtypes early bound propgets > with arguments are called with (), I never new about []. Hm, I didn't remember it but property access syntax IS even documented for quite some time here: http://starship.python.net/crew/theller/comtypes/#accessing-properties Besides that, I have now in the dyndispatch-branch added the call syntax to get properties, and extended the __getitem__ and __setitem__ calls so that [...] property access (both get and put) works with one or more arguments, in the same way as the early bound case. Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
Re: [comtypes-users] dyndispatch branch
Hi Thomas, In what svn revision did you add those changes you mentioned? (implemented __call__ and extended __getitem__ etc)? The last time comtypes/client/lazzybind.py was changed was in r450... is this correct? (svn tree is up to r459). I apologize if you just hadn't got around to committing it. Mick On 8/11/2008 7:49 AM, Thomas Heller wrote: > Michael Curran schrieb: >> Hi, >> >> Thanks for the explanation. If comtypes is already using the [] syntax >> for early bound interfaces, and if that is the most suitable way, then >> that sounds ok to me. I agree that it is important to keep dyn dispatch >> interfaces as compatible with early bound interfaces as possible. >> >> So, I also in that case do also think that __call__ should be >> implemented. In order so that named properties with optional or needed >> arguments can be called with () for getting, even though you could also >> use the [] syntax as well. >> In our projects, and I suspect others, comtypes early bound propgets >> with arguments are called with (), I never new about []. > > Hm, I didn't remember it but property access syntax IS even documented > for quite some time here: > > http://starship.python.net/crew/theller/comtypes/#accessing-properties > > Besides that, I have now in the dyndispatch-branch added the call syntax > to get properties, and extended the __getitem__ and __setitem__ calls > so that [...] property access (both get and put) works with one or more > arguments, in the same way as the early bound case. > > Thomas > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK& win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > comtypes-users mailing list > comtypes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/comtypes-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
Re: [comtypes-users] dyndispatch branch
Michael Curran schrieb: > Hi Thomas, > > In what svn revision did you add those changes you mentioned? > (implemented __call__ and extended __getitem__ etc)? > > The last time comtypes/client/lazzybind.py was changed was in r450... is > this correct? > (svn tree is up to r459). Michael, sorry - indeed it had forgotten to commit it. It is now in, as svn revision 460. -- Thanks, Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
Re: [comtypes-users] dyndispatch branch
Thanks. Interested to know what the timeframe is now in regards to getting dyndispatch merged in to trunk? I've been trying dyndispatch as a replacement to win32com IDispatch for my own project, and performance is just the same, if not a little better. Were there any other features that needed to be added? I'm certainly happy with how it is at the moment. I'd be happy to help with writing tests and or documentation if that is something that has to be done before merging --- Obviously I am quite keen to see this merged :) Mick On 20/11/2008 7:04 AM, Thomas Heller wrote: > Michael Curran schrieb: >> Hi Thomas, >> >> In what svn revision did you add those changes you mentioned? >> (implemented __call__ and extended __getitem__ etc)? >> >> The last time comtypes/client/lazzybind.py was changed was in r450... is >> this correct? >> (svn tree is up to r459). > > Michael, sorry - indeed it had forgotten to commit it. > > It is now in, as svn revision 460. > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
Re: [comtypes-users] dyndispatch branch
Michael Curran schrieb:
> Thanks.
>
> Interested to know what the timeframe is now in regards to getting
> dyndispatch merged in to trunk? I've been trying dyndispatch as a
> replacement to win32com IDispatch for my own project, and performance
> is just the same, if not a little better.
>
> Were there any other features that needed to be added? I'm certainly
> happy with how it is at the moment.
What I have added a few days ago was a way to access constants in a type library
from objects exposing IDispatch::GetTypeInfo() and ITypeComp (in the dyndisp
branch).
It works for early bound, late bound, and lazy bound objects (are these correct
names to a native english speaker?).
There is now a function (actually a class) named comtypes.client.Constants.
It can be used in this way:
>>> from comtypes.client import CreateObject, Constants
>>> x = CreateObject("Excel.Application")
>>> c = Constants(x)
>>> c.xlSaveChanges
1
>>> c.xlDoNotSaveChanges
2
>>>
A nice improvement would of course be to make events (ShowEvents,
GetEvents) work without generating the typelib wrapper, but that is too
much work at the moment. Don't you need it?
> I'd be happy to help with writing tests and or documentation if that is
> something that has to be done before merging --- Obviously I am quite
> keen to see this merged :)
My original plan was to work on compatibility with Python 3, and release then,
but if you're really waiting for it I can as well release now.
> Mick
Thomas
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
Re: [comtypes-users] dyndispatch branch
Hi Thomas,
Support for getEvents/showEvents would be great with dynDispatch.
However I must admit, that I didn't realize that it was possible to
support events purely with IDispatch.
My project doesn't technically rely on support for COM events in the
places where we use IDispatch, though that is not to say it won't in the
future.
But, I think that releasing a comtypes with dynDispatch so far is a
great step forward, even with out events. Of course, then at a later
stage if events were added that would also be great.
Thanks
Mick
On 27/11/2008 8:06 AM, Thomas Heller wrote:
> Michael Curran schrieb:
>> Thanks.
>>
>> Interested to know what the timeframe is now in regards to getting
>> dyndispatch merged in to trunk? I've been trying dyndispatch as a
>> replacement to win32com IDispatch for my own project, and performance
>> is just the same, if not a little better.
>>
>> Were there any other features that needed to be added? I'm certainly
>> happy with how it is at the moment.
>
> What I have added a few days ago was a way to access constants in a type
> library
> from objects exposing IDispatch::GetTypeInfo() and ITypeComp (in the dyndisp
> branch).
> It works for early bound, late bound, and lazy bound objects (are these
> correct
> names to a native english speaker?).
>
> There is now a function (actually a class) named comtypes.client.Constants.
> It can be used in this way:
>
from comtypes.client import CreateObject, Constants
x = CreateObject("Excel.Application")
c = Constants(x)
c.xlSaveChanges
> 1
c.xlDoNotSaveChanges
> 2
>
> A nice improvement would of course be to make events (ShowEvents,
> GetEvents) work without generating the typelib wrapper, but that is too
> much work at the moment. Don't you need it?
>
>> I'd be happy to help with writing tests and or documentation if that is
>> something that has to be done before merging --- Obviously I am quite
>> keen to see this merged :)
>
> My original plan was to work on compatibility with Python 3, and release then,
> but if you're really waiting for it I can as well release now.
>
>> Mick
>
> Thomas
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK& win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> comtypes-users mailing list
> comtypes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/comtypes-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
Re: [comtypes-users] dyndispatch branch
Michael Curran schrieb: > Hi Thomas, > > Support for getEvents/showEvents would be great with dynDispatch. > However I must admit, that I didn't realize that it was possible to > support events purely with IDispatch. > > My project doesn't technically rely on support for COM events in the > places where we use IDispatch, though that is not to say it won't in the > future. > > But, I think that releasing a comtypes with dynDispatch so far is a > great step forward, even with out events. Of course, then at a later > stage if events were added that would also be great. Michael, I have now (after the 0.5.3 release) merged the dyndispatch branch into the trunk, so the next release will be 0.6.0 with the 'dynamic=True' support you have been waiting for so long. I have to look into the remaining unittest failures, but I promise to make the 0.6.0 release next week. Thomas -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
[comtypes-users] dyndispatch branch (was: dynamic dispatch branch: fixing IEnumVARIANT)
Thomas Heller schrieb: > Michael Curran schrieb: >> Hi, >> >> After testing with the dyndispatch svn branch of comtypes, I relised >> that there is a problem with dynamic Dispatch and IEnumVARIANT being >> used together. >> >> The problem is that If you enumerate a dynamic dispatch object (you get >> an IEnumVARIANT object some how from it), that IEnumVARIANT object >> doesn't know it has to provide dynamic=True to variant._get_value. So, >> the IEnumVARIANT's next method returns objects with fully generated >> interfaces, rather than just dynamic dispatch support. >> >> I would suggest that comtypes.automation.IEnumVARIANT have an instance >> variable called dynamic, which can be set to False by default. But if >> true, then the Next method should provide dynamic=True when getting >> variants. This suggestion is now implemented. Here is the current state of the dyndispatch branch (in case Michael or someone else still cares about this stuff, which I hope!): The comtypes.client.CreateObject() function accepts an optional keyword argument 'dynamic' that defaults to False. The behaviour of the function is unchanged if 'dynamic=False', comtypes tries to generate and then imports the wrapper code for the object it creates. When CreateObject(..., dynamic=True) is called then no wrapper code is generated (well, if the object supports the IDispatch interface). If the com object exposes NO type information, then, as before, an instance of comtypes.client.dynamic._Dispatch is returned supporting method calls and property access by pure dynamic dispatch calls (GetIDsOfNames, and Invoke calls). If the com object exposes type information (and supports the ITypeComp interface), then an instance of the new module comtypes.client.lazybind.Dispatch is returned. Methods and properties are then bound by name, using ITypeComp.Bind() calls. Distributing the code for dynamic dispatch with or without type info over two different modules make the code a lot cleaner. > 3. Calling IDispatch.Invoke(...) is currently fairly slow. This is > because packing the arguments into the DISPPARAMS instance with ctypes > is very slow. This can probably be made a lot faster with a compiled > comtypes extension module. Also, the signature of IDispatch.Invoke() > in comtypes is wrong, it was a mistake to pass the invkind flags only > as keyword dictionary (and I thought it was clever!). This remains, but can be solved later if it turns out that it is really a problem. I would very much like to keep comtypes without any extension module, pure python. > 4. After playing around a little, I have the impression that it may be > better to create a separate subclass of a _Dispatch base class for > each COM object, and to generate the methods and properties in the > __init__ method from typeinfo. The big advantage is that the > resulting class has all methods (with parameter names!) and > properties that are available in the COM object, so code completion, > inspection, and so on will work. This I did not implement, it sounds much like early binding with all its problems that we want to get rid of. The dynamic dispatch code does everything on demand only (although I tried to cache the results of expensive calls to ITypeComp). -- Thanks, Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
