[Python-Dev] Inline and SWIG

David Beazley beazley@cs.uchicago.edu
Wed, 22 Aug 2001 21:16:02 -0500 (CDT)

 > It isn't as trivial as you think. It is essentially a superset of SWIG's
 > Python-related functionality. Don't forget that an important part of it
 > is trying to autodetect types. It quickly gets into figuring out structs
 > and then classes and then templates and then madness ensues. Obviously
 > you have to decide how much you are going to support and just require
 > "compliant" wrappers for the rest. Using SWIG might allow you to offload
 > a bunch of that effort for PyInline::C.

I've looked briefly at Inline and agree that it's a pretty nifty
approach.  However, usability aside, it's got a number of pretty major
limitations once you start getting into structure wrapping, C++
classes, and other advanced types of extension wrapping. I think a
common misconception about wrapper generation tools in general is that
it's just a matter of hacking up a quick parser and throwing something
together in a couple of days. The *real* problem IMHO is actually
trying to figure out how to properly handle all of the facets of the
C/C++ type system (pointers, references, qualifiers, classes,
templates, typedef, inheritance, multiple inheritance, member
pointers, pass by value, etc.) and how that's supposed to hook into
Python.  What's worse, if you get *ANY* part of the type system wrong,
everything becomes a hellish nightmare later (and I can speak from 
personal experience on this :-).

We've been working on an upcoming major new SWIG release for quite
some time now and about 80% of that work has been related to
redesigning the internal type system.  Maybe this sort of thing is
obvious to everyone else and I'm missing some trivial point, but I
sure haven't found the C++ type system to be this totally trivial 
thing I could just hack up in a few days and stick in a code generator!  

In any case, I think the coolest thing about Inline is the ability to
add small little bits of C code on-the-fly without having to restart
the interpreter.  That's a pretty neat trick that would probably be
useful in the context of working with larger C extensions.  I'm not
sure I'd want to build a huge 400 function C extension module with
that kind of approach, but something like that would definitely be
useful for prototyping and adding code on the fly.  I almost wonder if
something like SWIG could be used behind the scenes to do code
generation for something like that.