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

[Niall Douglas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19 Sep 2003 at 8:14, Prabhu Ramachandran wrote:

>     ND> Bottom-up projects like SWIG easily get success with simple
>     ND> C++ but will find it geometrically harder to add increasingly ND>
>     complex C++. I went with boost.python because it seemed to me ND> 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. 

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

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

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

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

>     ND> features. Also, pyste looked very attractive whereas SWIG
>     ND> requires custom written interface files which would take me
>     ND> weeks to write initially and a high quantity of maintanence
>     ND> time whenever the underlying library was changed (often).
> 
> Huh?  Pyste files and SWIG interface files are really quite similar.

They're not. A pyste file for an entire complex header file can be 
five lines including setting return policies. And if you base your 
return policy setting code around the object hierarchy, you can 
substantially save on that again. SWIG interface files are usually 
the same size as the header file they're specifying.

> 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?

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

>     ND> pyste scripts are way, way shorter. SWIG interface files are a
>     ND> simplified duplicate of the C++ header - that IMHO is stupid
>     ND> because every time the header file changes, you must mirror
>     ND> the changes in the SWIG interface file.
> 
>  %include "your_header.hpp"
> 
> How much simpler than that can you get?

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

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

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

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

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP2tP7sEcvDLFGKbPEQJmDwCcCq7zbdbY6ATpLX5SMMWrahYHS2gAn0pJ
YMBypcIjG6Nrpa1qH+kWxxeA
=Cke7
-----END PGP SIGNATURE-----