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