Łukasz Jakubowski wrote: > Please look up the following forum post: > http://resource.dopus.com/viewtopic.php?f=12&t=24125&p=136297&hilit=python#p136297 > > Is this really some indication of a pywin32 problem? > > Please mind that the provided example call should be really: > comm = DOpus.Create().Command().CommandList('u') > but using () does not work (a version without parentheses needs to be used > or _FlagAsMethod). > CommandList accepts 0 or more arguments, while Create and Command accept 0 > arguments. > > It seems using () should result in proper calling of a COM object?
This is really an ugly situation. They are wrong to say that this is "100% a bug in Python". It's partly their fault as well. The problem is that the IDispatch mechanism is ambiguous, and they have designed their object model in a way that absolutely invites misinterpretation. Their CommandList object supports calls with no parameters, it supports calls with one parameter, and it supports a default dispatch. By being overly accommodating, technically speaking, their object has publicly advertised that it supports Python's interpretation (fetching a property result and calling its default dispatch), and there is no way for them to say they prefer one over the other. Python happens to prefer the default dispatch solution when given a choice, and this is the result. At the core, this decision is made in CDispatch.__call__ in win32com\client\dynamic, but that's so fundamental to IDispatch operation that I don't know the implications of changing the order. In the short term, I suspect you could work around this in an ugly way: cmd = DOpus.Create().Command() cmd._olerepr_.defaultDispatchName = None comm = cmd.CommandList('u') -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. _______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32