[python-win32] Potential problem with calling Invoke
Łukasz Jakubowski
lukaszj at onet.pl
Tue Apr 12 17:21:52 EDT 2016
Hi Tim,
Thanks for taking a look.
Do you have maybe some quick idea for some way of fixing it with
intermediate code, so that fe. calls are verified for result and reissued
in another style/_FlaggedAsMethod and reissued - and _FlagAsMethod or
using cmd._olerepr_.defaultDispatchNam later in code is not required?
I imagine that it could work as some extra import, and then would allow
using all the Directory Opus API without any special provisions. I don't
want to mess with pywin32 code.
Looks like great python exercise :)
Regards,
Lukasz
Dnia Mon, 11 Apr 2016 19:20:01 +0200, Tim Roberts <timr at probo.com> napisał:
> Ł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')
>
--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/
More information about the python-win32
mailing list