CallDLL/WinDLL vs Python Wrapper Extension (Win32)

[Robert Kern]

In article <MPG.13446350543afce59896b5 at news.nettally.com>,
	Tom Funk <_spam_sux_tdfunk at _spam_sux_nettally.com> writes:

[snip]

> 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 
of it.  

> 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 
> this.

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.

-- 
Robert Kern
kern at caltech.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter