[Python-3000] Ctypes as cross-interpreter C calling interface
Guido van Rossum
guido at python.org
Thu Aug 10 19:50:24 CEST 2006
I worry that this may be too ambitious to add to the already
significant load for the Py3k project. You've seen my timeline --
alpha in early 07, final a year later.
Don't get me wrong! I think that completely changing the FFI paradigm
(as opposed to evolutionary changes to the existing C API, which py3k
is doing) is a very worthy project, but I'd rather conceive it as
something orthogonal to the py3k transition. It doesn't have to wait
for py3k, nor should py3k have to wait for it. Tying too many projects
together in terms of mutual dependencies is a great way to cause total
On 8/9/06, Paul Prescod <paul at prescod.net> wrote:
> Thanks for everyone who contributed. It seems that the emerging consensus
> (bar a security question from Guido) is that ctypes it the way forward for
> calling C code in Python 3000. I'd like to clarify what this might mean:
> 1. Is ctypes and pure python fast enough for most real-world extension
> modules like PyOpenGL, PyExpat, Tkinter, and socket programming? I know that
> experimentation is ongoing. Are any results in?
> 2. If not, will Python 3000's build or runtime system use some kind of
> optimization technique such as static compilation ( e.g. extcompiler) or
> JIT compilation to allow parts of its library (especially new parts) to be
> written using ctypes instead of C?
> 3. Presuming that the performance issue can be worked out one way or
> another, are there arguments in favour of interpreter-specific C-coded
> extensions other than those doing explicitly interpreter-specific stuff (
> e.g. tweaking the GC).
> 4. Will the Python 3000 standard library start to migrate towards ctypes
> (for new extensions)?
> Paul Prescod
> Python-3000 mailing list
> Python-3000 at python.org
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000