[pypy-dev] Sprint Discussions: C++ Library Bindings

Carl Friedrich Bolz cfbolz at gmx.de
Thu Oct 23 14:36:00 CEST 2008


Hi David,

David Wilson wrote:
> I just read about this on the PyPy status blog and find myself
> wondering about the strategies you considered before settling on the
> Reflex approach.
> 
> I've had an extension to ctypes in mind for quite some time that
> involves simply leaving the debugging segments present in a shared
> library in order to be able to introspect them and provide type-safe
> access to the code within.
> 
> The idea is simple: implement a DWARF/stabs/etc. interpreter that can
> construct Python types and function proxies to represent what is
> present in the shared library. Initially I wanted this for C, so that
> a Python programmer needn't manually declare structs using quirky
> ctypes class definitions, but I can't see why a (rather more complex)
> implementation couldn't reconstruct C++ classes with their associated
> class/member functions.
> 
> The obvious benefit is that a C/C++ library need not be modified at
> all in order to benefit, other than not being stripped of debugging
> information during its build. Linux distributions are slowly gaining
> infrastructure that makes this almost zero cost (e.g. the Debian
> python-dbg package).
> 
> I've had the DWARF specification sitting on my desktop for about 2
> months now, waiting for me to validate my idea.
> 
> I'm wondering if you've considered this approach, and if so, why you
> discarded it.

One problem of this approach (in addition to what Maciek mentioned) is
that the debug information is quite large. It contains much more
information that what is needed for doing language bindings, e.g. also
detailed information about the inside of functions ("when the PC is
this, these variables are in those registers"). The Reflex information
should be rather small in size, compared to that.

Cheers,

Carl Friedrich



More information about the Pypy-dev mailing list