Home Original page

SWIG and Callbacks

David Abrahams david.abrahams at rcn.com
Mon Jun 17 10:18:12 EDT 2002 
"Jim" <jbublitzNO at SPAMnwinternet.com> wrote in message
news:3D0D3223.5070500 at SPAMnwinternet.com...
> David Abrahams wrote:

> > I'd really like to know what you find preferable about sip -- aside your
own
> > familiarity with it, of course, which for me usually counts more than
any
> > other single factor ;-). I'm actively developing v2 of Boost.Python and
> > would really like to make it the best tool possible for this job, so it
> > would be useful to know more.
>
> I inherited sip rather than choosing it after 'careful evaluation',
> and certainly familiarity is a big part of it. In fact I've only
> given other alternatives a cursory look, so what I like about sip
> may already be available in Boost or other packages.
>
> The biggest plus for sip is that the 'IDL' is the h file syntax
> with a few subtractions (variable names, forward declarations,
> inline code, but inline methods stay), so that most of the
> description file creation is easy to automate and still not
> that hard to do manually for a small number of files. sip
> supports most C++ h file syntax.


Hmm, I wonder about that. The C++ type system is pretty sophisticated (to
the point of being able to represent entire compile-time programs!) and all
of the parser-based wrapping systems I've seen eventually fail to handle
some constructs I use, especially if I'm wrapping template-based code.
That's part of the reason I chose to use the compiler itself in
Boost.Python. The compiler (in theory) has no problem with C++ syntax ;-)

On the other hand, I realize there's a large category of simple C++
interfaces which can be parsed will less-than-complete machinery.

> The other features that are helpful on large projects are the
> built-in support for versioning

How so? Can you say more about this?

> and embedded docs (both also fairly
> easy to automate),

Do you mean docstring generation?

> as well as support for 'platforms' and
> 'features'. So for example PyQt (not my project) can support Qt
> from 1.4.2 through 3.0.4 with different mixes of features (with
> SQL or not, QTable or not) across Windows, Linux/Unix/BSD, and
> (soon) Mac, with a single set of source files, and still be
> manageable by one person.

Boost.Python works on a similar range of platforms.
I'm not sure if this configuration stuff is an appropriate job for a
wrapping system to provide specific support for; what's the argument for
integrating it with the wrapping system?

> sip is flexible enough that you can handwrite code to "Pythonize"
> C++ code (return a Python list or dict, or for example,
> 'void rgb (int&, int&, int&)' returns (int, int, int) and takes
> no arguments in PyKDE), or create type substitutions/conversions
> ('mapped types') once and re-use them across a project. You can
> do C++ with anything of course, but sip has it well-integrated
> (manageable) and has support code to make it easier (arg unpacking,
> object conversions, etc). IIRC, Boost might not need handwritten
> C++ code quite as much.

Not sure about this; we'd need to compare specific functionality.

> I suppose those are a series of small advantages, but the end
> result seems to me that you write less code

Are you counting the IDL file? That's code, IMO.

> and you do it in
> fewer but well-known locations. It seems to add up to a big
> difference on a large project.
>
> Boost (IIRC) also has a big advantage in being able to bind much
> more selectively.

Can you explain what you mean by that?

> sip is easiest when binding everything in a lib
> and probably takes a little more effort to be selective - you
> can do it, but it isn't as 'mindless' (ie automatable) as most
> sip file creation is. And of course Boost is actually
> documented - no small thing.

Heh, yeah. Unfortunately, documentation is often harder than coding. Even
the current official release of Boost.Python is not very well-documented.
We're working hard to correct that for v2, which is in pre-release.

> How would you see Boost performing on a very large project -
> say 10 libs, 20 classes/lib, 10 exposed methods/class (2000
> methods overall)?

See http://cctbx.sourceforge.net/
Also
http://mambo.peabody.jhu.edu/~karlmac/publications/gamera_python_2001/gamera
.html

Of course, these don't prove anything, since wrapping is a nontrivial job
and people quickly get invested in whatever is working for them. You *can*
wrap a large project with Boost.Python, but whether it's easier than with
sip...?

> I haven't looked at Boost in a while -
> could you incorporate conditional compilation (eg versions,
> features)

It's C++; you can use #ifdef in just the same way that the rest of the C++
code surely does.

> and embed docs easily?

Docstring support is on the todo list for v2. It will be a matter of passing
a string literal to the def() function which wraps a function pointer:

class_<Foo>()
   .def_init(args<int>(), "Creates a Foo with the specified number of Bars")
   .def("get_name", &Foo::get_name, "get the Foo's name")
   .def("set_name", &Foo::set_name, "set the Foo's name")
   ;

> Could you automate code generation to some extent?

Not sure what you have in mind here. In a sense, the metaprogramming
techniques used by Boost.Python already *do* code generation.

> The automation for generating
> PyKDE is pretty crude at the moment, and in all fairness
> isn't generally available, so this example would be a lot
> of work using sip as it comes out of the box. Is Boost
> really intended for projects of this size (there probably
> aren't many), or do you have different goals for it?

Yes, Boost.Python is intended for large projects. One of the largest
projects I've ever heard is using it at Lawrence Livermore Labs, for
example.

-Dave
More information about the Python-list mailing list