Arbitary VTABLE/Python

Discussion in 'Python' started by John Smith, Apr 15, 2004.

  1. John Smith

    John Smith Guest

    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 Smith, Apr 15, 2004
    #1
    1. Advertising

  2. John Smith

    John J. Lee Guest

    John Smith <> 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
     
    John J. Lee, Apr 18, 2004
    #2
    1. Advertising

  3. John Smith

    Your name Guest

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



    (John J. Lee) wrote in news::

    > John Smith <> 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
    >
     
    Your name, May 4, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pani
    Replies:
    2
    Views:
    363
    Alexander Terekhov
    Jul 23, 2003
  2. Daniel Heiserer
    Replies:
    1
    Views:
    2,919
    Artie Gold
    Aug 1, 2003
  3. Aryeh M. Friedman

    Getting an arbitary date the *RIGHT* way

    Aryeh M. Friedman, Jan 21, 2009, in forum: Java
    Replies:
    6
    Views:
    365
    Roedy Green
    Jan 23, 2009
  4. George Vlahakis

    Receiving arbitary 2-dimensional tables in a WebService method

    George Vlahakis, Jun 27, 2006, in forum: ASP .Net Web Services
    Replies:
    1
    Views:
    118
  5. Aryeh M. Frierdman

    Freezing an arbitary object

    Aryeh M. Frierdman, Jul 6, 2003, in forum: Ruby
    Replies:
    8
    Views:
    129
    Robert Klemme
    Jul 7, 2003
Loading...

Share This Page