[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