Arbitary VTABLE/Python

[John Smith]

Sorry if these question has been answered
already, our Web searches/FAQs left us
with more questions than answers.

Few of us at a very large corporation
are struggling to figure out if Python
stable & scalable for our needs.
(Sorry if this question has been answered
already, our Web searches/FAQs left us
with more questions than answers)


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?)

What combinations of tools/modules does one recommend
for transitioning to Python based environment
where large third party COM+ based infrastructure (C++)
already exists? How stable/scalable/fast are these solutions?

Our existing C++ code base runs both on Windows & Unix
and we don't have to worry about supporting .NET right now.

Thanks.

 

[John J. Lee]

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

 

[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)?

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