[C++-sig] SWIG vs Pyste (was: Re: [Implementation] Calling wrapped functions, converters, policies)

[Prabhu Ramachandran]

>>>>> "ND" == Niall Douglas <s_sourceforge at nedprod.com> writes:

    >> complex C++. I went with boost.python because it seemed to me
    >> to be naturally more easily extendable for advanced C++
    >>
    >> Having used both tools I find that hard to believe.  SWIG from
    >> CVS handles quite complex C++.  AFAIK the only thing it does
    >> not support yet is nested structures/classes.

    ND> It also didn't play nice with compile-time metaprogramming
    ND> constructs when I tried it. I was also slightly concerned
    ND> about exception translation if I remember, but that could
    ND> simply be the lack of docs SWIG suffers from.

As I said, its not perfect and will not improve without users
reporting problems.

    ND> Either way, SWIG's C++ parser will likely never be able to
    ND> handle full unadulterated C++. It'll always need some form of
    ND> simplification or hinting. That's because SWIG can't
    ND> "understand" C++, whereas Boost.Python does through
    ND> compile-time introspection.

True, but a while back C++ compilers didn't understand C++ either.

    >> True, Pyste files are Python files and interface files are not
    >> but the SWIG pre-processor is quite powerful.

    ND> I am absolutely sure it can be nowhere near as powerful as a
    ND> python script.

Sure, its not as powerful as Python and it would be nice if interface
files were Python files.  However, interface files are certainly quite
powerful enough to do quite a bit.

[snip]

    >> You need to write the interface files for both and both will
    >> need changing if the underlying library changes.  I don't see
    >> how you avoid that by using Pyste instead of SWIG?

    ND> I've gone further though and have a python script which scans
    ND> the include directory of the C++ library, generates a pyste
    ND> file for each one which has changed since last invocation
    ND> using a customisable rule set defining differences and then
    ND> invokes pyste. This means the total maintanence cost is merely
    ND> maintaining the return policies file - everything else is
    ND> totally automated.

Interesting, but what prevents you from generating SWIG interface
files in similar manner?

[snip]

    >> %include "your_header.hpp"
    >>
    >> How much simpler than that can you get?

    ND> SWIG barfed loudly with the unmodified headers I tried feeding
    ND> it.  I'm sure things have improved, but quite honestly either
    ND> maintaining alternative code within #ifdef SWIG areas or even
    ND> a simplified duplicate is too expensive when you have 232
    ND> header files exposing a public interface - and that number is
    ND> growing.

Yes, the parser will need work but I find that the developers are
quite responsive when bug reports are submitted.

    >> If you need to pick classes/functions then you can use %ignores
    >> to ignore what you don't want.  Yes, it is a problem that you
    >> can't pick specific classes from a bunch of them.  Perhaps that
    >> would be a good feature to suggest on the SWIG lists?  Note
    >> that you do get some extra flexibility with the SWIG approach.

    ND> Out of interest, if you had to produce python bindings for the
    ND> whole Boost library, would you use SWIG or Pyste?

I don't know.  I'd probably try both and see which does the job.
Given the state of gcc my guess is that just compiling the
Boost.Python version will take forever.

    ND> I should also that I haven't looked at SWIG in the last few
    ND> months and when I did, it was purely in evaluation terms - not
    ND> for serious bashing. So I may be wrong, but I'm pretty sure as
    ND> a general rule I'm right.

Well, in my personal evaluation I've been a more successful with SWIG
in less time than with Pyste.  I've wrapped about 90 odd classes.
Sure, the code I've wrapped is *nowhere* near as complex as the Boost
library but its something and a decent data point for me.  This is not
to say that Boost.Python is not good enough, its probably just me but
hey I would not be on this list if I didn't think highly of
Boost.Python and Pyste.  The only reason I am replying on this thread
is that I think you are being a little too dismissive of SWIG and that
goes against my (admittedly limited) experience.

cheers,
prabhu