On Aug 28, 2011, at 7:27 PM, Guido van Rossum wrote: > In general, an existing library cannot be called > without access to its .h files -- there are probably struct and > constant definitions, platform-specific #ifdefs and #defines, and > other things in there that affect the linker-level calling conventions > for the functions in the library.
Unfortunately I don't know a lot about this, but I keep hearing about something called "rffi" that PyPy uses to call C from RPython: <http://readthedocs.org/docs/pypy/en/latest/rffi.html>. This has some shortcomings currently, most notably the fact that it needs those .h files (and therefore a C compiler) at runtime, so it's currently a non-starter for code distributed to users. Not to mention the fact that, as you can see, it's not terribly thoroughly documented. But, that "ExternalCompilationInfo" object looks very promising, since it has fields like "includes", "libraries", etc. Nevertheless it seems like it's a bit more type-safe than ctypes or cython, and it seems to me that it could cache some of that information that it extracts from header files and store it for later when a compiler might not be around. Perhaps someone with more PyPy knowledge than I could explain whether this is a realistic contender for other Python runtimes?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
