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/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
