[sword-devel] Python bindings for libsword with SIP

[Jonathan Morgan]

On Sat, Nov 28, 2009 at 3:37 PM, Troy Melhase <troy.melhase at gmail.com> wrote:
> Greetings,
>
> I've created a Python binding for libsword via SIP[1].  The code is here:
>
>    http://github.com/natural/sword-sip
>
> The binding is mostly complete, certainly the larger classes and
> methods.  I'd like it if folks who use the SWIG bindings could also
> try to build this binding with SIP and send me any feedback, good, bad
> or indifferent.
>
> As to why:  SWIG is great for what it does, but what it produces isn't
> the most natural for Python  programmers.  My motivation was to
> replace code like this:
>
>    >>> install_source.directory = SWBuf("/some/path")
>
> With code like this:
>
>    >>> install_source.directory = "/some/path"
>
> SIP provides this by mapping to and from native python types where
> instructed.  I've got it working for SWBuf, ModMap, SectionMap,
> ConfigEntMap, etc.
>
> Another minor benefit is size:  the resulting sword.so file is 1454499
> bytes on my system, whereas _Sword.so is 1949642.  The SIP bindings
> require the SIP runtime, which is another 70k, but that dependency is
> shared if your project is already using it (and it's smaller than the
> Sword.py helper used by _Sword.so).

It's certainly an interesting idea, but from my perspective, the code
BPBible uses to interact with SWIG just works.  On the whole frontend
code is not calling SWORD/SWIG directly, and so I at least have never
found the problems you describe.  I was surprised to see what you said
about SWBuf, ModMap and friends.  It turns out we have 14 uses of
SW.Buf, and I don't think I have put any of them in (we do use c_str()
a few more times than that).  ModMap, SectionMap, ConfigEntMap, and
friends don't appear to be created in our code, though they are
accessed using the interface SWIG provides and it's not always neat.
We have had the occasional bug in SWIG that has been worked around
(particularly in SWIG's iteration over STL types, which has the
unpleasant side effect of occasionally causing access violations).
It's also worth considering the overhead of converting types like
SWBuf to native Python types, since some of the buffers have lots of
text in (not that I'm claiming SWIG is efficient).

We probably could replace SWIG with SIP, but it is unlikely we would
do it soon just because BPBible works and works now with what is
there.  The changes you describe would be far more likely to benefit
the Python programmer working with the SWORD API directly than they
would be to benefit us, and so I'm not keen on making changes to
working code as a priority.

Jon