[C++-sig] Announcing pybindgen

Gustavo Carneiro gjcarneiro at gmail.com
Sun Sep 30 22:23:23 CEST 2007

On 30/09/2007, Joseph Lisee <jlisee at gmail.com> wrote:
> Gustavo Carneiro <gjcarneiro <at> gmail.com> writes:
> >
> >
> > (manually replying from copy-pasting the archives because my c++-sig
> subscription was disabled by accident).Nat Goodspeed wrote:       >Gustavo
> Carneiro wrote:>>   Hello all,>>
> > >>   I'd like to announce a new project for producing python extensions,
> >>
> called PyBindGen.  It follows a radical new path for Python bindings >>
> generation: it is itself written in (gasp!) Python!  And it does not
> > >> even use C++ templates at all! >Interesting! I would be curious to
> see you
> contrast it with the Py++ >project:>>
> > http://www.language-binding.net/pyplusplus/pyplusplus.html>>to get a
> sense of
> when I might choose to use one vs. the other.I know Py++.  You cannot
> compare
> Py++ with PyBindGen.  I would say that PyBindGen replaces
> > Boost.Python.  Py++ is a layer on top of Boost.Python.  Py++ generates
> Boost.Python module definition sources through automatic scanning of C++
> header
> files.  PyBindGen lacks the header files scanning feature that Py++
> provides,
> and I really miss that feature in PyBindGen.  I hope that someone (maybe
> me)
> finds time to work on that for PyBindGen, some day...  I'm not sure if
> Py++ is
> modular enough to be able to receive a different code generation backend
> besides
> > Boost.Python (Roman, feel free to comment :).Although I like Py++ a lot,
> I
> really hate Boost.Python.  Maybe it's because of my lack of skill in
> understanding C++ templates, but I feel like Boost.Python hides too many
> details
> underneath a layer of cryptic to follow set of C++ templates, while I need
> to
> see the generated code in order to check that memory management details
> are
> being declared and implemented correctly.  In addition, to compile
> > Boost.Python based bindings your users need to have the boost python
> library
> and header files installed.  In contrast, PyBindGen generated extensions
> only
> require python development header files in order to compile, nothing
> more.  I
> also think
> > Boost.Python extensions compile to rather large modules...Regards,--
> Gustavo
> J. A. M. CarneiroINESC Porto, Telecommunications and Multimedia Unit"The
> universe is always one step beyond logic." -- Frank Herbert
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig <at> python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >
> Let me chime in on the code generation side too.  Just taking a look at
> your
> example, you have to write almost twice as much python wrapping code as
> there is
> C++ in the header you are wrapping.

But the generated code is nearly 10 times as large as the Python code the
generates it, while still being relatively compact (I think it's very much
smaller than an equivalent boost.python module in terms of code size,
although I have not bothered yet to create the same project with both
boost.python and pybindgen to compare accurately).

  Is this case for all headers you wish to
> wrap, or is it because you were overexercising your library?

No overexercising; it's like this.

I welcome a project that removes the longer compile times of Boost.Python
> .  Yet
> one of those reasons for the long compile times is because its hard to
> understand template magic is doing quite a bit of work for you.

I think Boost.Python has compile-time introspection for function/method
parameters, and so you only have to tell Boost.Python a list of class names
and method names; that's the main reason the BP interface description file
is smaller.

Admittedly, PyBindGen could use some introspection itself, but that can be
an additional layer.  I would like to have a layer that uses pygccxml, or
something like that.  Some day when I have more time... In the mean time I
believe the PyBindGen Python API is already rather useful, if a bit more
verbose than boost.python.

Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20070930/c186d4a2/attachment.htm>

More information about the Cplusplus-sig mailing list