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

Maciej Fijalkowski fijall at gmail.com
Thu Oct 23 14:19:06 CEST 2008


On Tue, Oct 14, 2008 at 6:39 PM, David Wilson <dw at botanicus.net> wrote:
> Hi there,
>
> 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.

We're not settling on it. It's rather "first to try".

>
> 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 problem with such approach is usually that this is too low level.
Gaining back lost abstraction level is usually hard and sometimes
impossible. I cannot say exactly that this approach is not worth
following - I'll just try to use reflex first as it seems people are
using it to do complex tasks. Of course feel free to prove that I'm
wrong, right now I'm more thinking about possibilities (hence
questions on blog to people to provide input), than settling on
anything.

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

The answer is simple: we didn't consider it yet :-)



More information about the Pypy-dev mailing list