Ł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
