CallDLL/WinDLL vs Python Wrapper Extension (Win32)
kern at caltech.edu
Sat Mar 25 10:44:01 CET 2000
In article <MPG.13446350543afce59896b5 at news.nettally.com>,
Tom Funk <_spam_sux_tdfunk at _spam_sux_nettally.com> writes:
> I've just started reading the Embedding/Extending Python docs. I've
> downloaded four chapters of SWIG. I think SWIG is probably overkill
> since I get the first impression that it's designed to wrap C/C++ source,
> not header files alone.
Actually, you usually run SWIG over a header file or a marked up version
> I've also looked at some of the docs and
> examples that come with Sam Rushing's DynWin module that use calldll,
> gencb and windll.
> I'm trying to decide the best approach to take.
> The API consists of 53 #defines (mostly numeric constants), 2 enums, 7
> typedef'd structs, and 24 function calls. Of the 6 required callback,
> all take a struct as an argument.
FWIW, see Chapter 9 of the SWIG User's Manual about the callbacks.
> I don't want to expose the end user to the (ugly) API directly, rather I
> want to python-ize it. i.e., create a Library class that exposes the
> source code as a dictionary or list. Provide an Application class that
> wraps a group of libraries and exposes the libraries as a collection
> (dictionary or list). Move, copy and compile functions would become
> methods of a library rather than distinct function calls. Things like
With SWIG, you would expose the pure API and write a Python wrapper
around it. The wrapper is generally pretty easy with SWIG's shadow
classes to work with.
> So, any takers? Does anyone have any feedback on what might be a
> preferred approach?
SWIG will probably get you up and running really fast. You can work out the
API you want to expose pretty quickly. However, I haven't used windll, so I
can't offer a comparison.
kern at caltech.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Python-list