| |||||||||||||
C extensionsC extensionsPosted May 16, 2011 1:35 UTC (Mon) by kingdon (subscriber, #4526)Parent article: A brief experiment with PyPy
As for the C extensions, sounds like Python needs an equivalent to the ruby FFI, which enables ruby code to talk to a C library without any close ties to the internals of the ruby implementation. See https://github.com/ffi/ffi/wiki/
(Log in to post comments)
C extensions Posted May 16, 2011 2:54 UTC (Mon) by njs (guest, #40338) [Link]
Python has that -- 'ctypes', in the standard library since 2006 -- but that doesn't mean that all existing code uses it. (Nor is it necessarily a great match for extensions that are extending the interpreter in low-level ways, as opposed to just wrapping an existing C library.)
C extensions Posted May 16, 2011 18:33 UTC (Mon) by foom (subscriber, #14868) [Link]
ctypes is not a great way of wrapping a C library either, since it doesn't give you access to the header files, which you need to use if you want portability.
Redefining all the structs/#defines/etc manually in ctypes is a great way to make a completely unportable library wrapper.
C extensions Posted May 16, 2011 18:54 UTC (Mon) by njs (guest, #40338) [Link]
Yeah, it works well for some simpler cases, but that's why I use cython :-).
(Actually, I think most of the times I've used ctypes were to commit horrors by poking at the innards of the interpreter -- casting id(myobj) to a pointer and then screwing with C-level fields. It's not easy to guarantee portability between different implementations of a language!)
|
|||||||||||||