Arbitary VTABLE/Python

[John J. Lee]

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