[Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

[Dan Stromberg]

On Tue, Aug 30, 2011 at 10:05 AM, Guido van Rossum <guido at python.org> wrote:

> On Tue, Aug 30, 2011 at 9:49 AM, "Martin v. Löwis" <martin at v.loewis.de>
> wrote:
>  The problem lies with the PyPy backend -- there it generates ctypes
> code, which means that the signature you declare to Cython/Pyrex must
> match the *linker* level API, not the C compiler level API. Thus, if
> in a system header a certain function is really a macro that invokes
> another function with a permuted or augmented argument list, you'd
> have to know what that macro does. I also don't see how this would
> work for #defined constants: where does Cython/Pyrex get their value?
> ctypes doesn't have their values.
>
> So, for PyPy, a solution based on Cython/Pyrex has many of the same
> downsides as one based on ctypes where it comes to complying with an
> API defined by a .h file.
>

It's certainly a harder problem.

For most simple constants, Cython/Pyrex might be able to generate a series
of tiny C programs with which to find CPP symbol values:

#include "file1.h"
...
#include "filen.h"

main()
{
printf("%d", POSSIBLE_CPP_SYMBOL1);
}

...and again with %f, %s, etc.  The typing is quite a mess, and code
fragments would probably be impractical.  But since the C Preprocessor is
supposedly turing complete, maybe there's a pleasant surprise waiting there.

But hopefully clang has something that'd make this easier.

SIP's approach of using something close to, but not identical to, the .h's
sounds like it might be pretty productive - especially if the derivative of
the .h's could be automatically derived using a python script, with minor
tweaks to the inputs on .h upgrades.  But sip itself is apparently C++-only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110901/170b2146/attachment.html>