Arbitary VTABLE/Python

[Your name]

can you please elaborate on:

> It has, only quite recently, acquired the
> ability to implement arbitrary vtable interfaces.

Does this mean that one can call
QueryInterface functionality from Python?
Having very large C++
COM interfaces (and not all of the interfaces
support automation, only some support),
can I replicate what we are doing in C++
WITHOUT going through external interface
libraries (ctypes, boost etc)?



jjl at pobox.com (John J. Lee) wrote in news:87isfy5egr.fsf at pobox.com:

> John Smith <skjj at earthlink.net> writes:
> [...]
>> We have very,very large C++ applications
>> that talk to third part COM based server(s),
>> both in-proc & out-of-proc 
>> 
>> - For large arbitary vtable based interfaces, 
>> what is the best approach from Python?
>> 
>> We looked at FAQs, DOCs (including ActiveState), WEB
>> searches, and saw references to SWIG, PythonCOM extensions
>> BOOST.Python etc, and some problems people have reported using
>> arbitary vtable interfaces from PythonCOM (BTW: where is are DOCs on
>> one using/creating PythonCOM extensions? From our
>> WEB searhces, it looks like 'makepy' may not
>> work under all situations?)
> [...]
> 
> makepy applies only to IDispatch-based interfaces.  PythonCOM doesn't
> call arbitrary vtable interfaces yet (unless it has very recently
> grown that ability).  It has, only quite recently, acquired the
> ability to implement arbitrary vtable interfaces.  Of course, you can
> always write an extension in C or C++, and integrate that with
> win32all, but that's a bore, and I'm not sure it's a well-documented
> process.
> 
> (Just to clear up any possible confusion: PythonCOM is part of
> win32all (which itself is also bundled with ActiveState's Python
> distribution, if they're still doing that).  Mind you, I can never
> remember whether PythonCOM is an internal part of win32all, or an
> umbrella name for win32all's COM functionality, or what... so I always
> just say 'win32all', or win32com, if I specifically mean that module
>:-)
> 
> So, win32all is nice, but it doesn't do what you want (call arbitrary
> vtable COM interfaces), at least without doing some wrapping and
> knowing about win32com's / pythoncom's internals.
> 
> The most Pythonic route is ctypes.
> 
> ctypes is quite elegant, thin and small (in contrast to win32all).
> It's still fairly new, but because it's relatively small, if you've
> got highly experienced COM developers on board, I'd imagine you're not
> going to struggle too much with any problems that do crop up.  I used
> an earlier release and bumped into two bugs when I played with it, but
> found they were already fixed in CVS.  It's more stable now (6 months
> or more since the version I used was released).  Recent testimony:
> 
> http://mail.python.org/pipermail/python-list/2004-April/214912.html
> 
> 
> The other way is to write your client code in C++, then wrap it.
> Boost Python is pretty much the standard way to do that for Python.
> I've never used it.  I guess it's useful as an insurance policy if
> ctypes fails at some task for you.  I think Mark Hammond (primary
> win32all author) )has his own ways of wrapping COM interfaces, but
> whether they're suitable for public consumption I don't know.
> 
> If my goal were at all related to C++, I wouldn't use SWIG, unless it
> has advanced quite a bit since I last looked (a year or so ago).
> Boost Python is generally agreed to be a better solution unless you
> need to expose things to multiple scripting languages.
> 
> 
> John
>