[Python-3000] Ctypes as cross-interpreter C calling interface

Paul Prescod paul at prescod.net
Mon Aug 14 20:40:04 CEST 2006

I guess I don't see ctypes and Parrot solving the same problem at all. My
idea with ctypes was the opposite of choosing a new runtime. It was to help
various runtimes (PyPy, Jython, IronPython, CPython 2.5, CPython 3.0,
Parrot, ...) to compete on their own merits (primarily performance and
interoperability) and not on the basis that they don't support some Python
library whether it be "crypt" or "pyopengl". It would also be nice to move
beyond the situation where everyone in the world must re-release their C
modules (no matter how trivial) every time Python goes through a minor
upgrade. Does Parrot these problems or exacerbate them?

Also, Parrot seems like a bit of a random choice considering the fact that
there are many candidates for a next-generation Python runtime: PyPy,
IronPython/mono, etc. They have both come much further, much quicker, than
Parrot. I'm a bit skeptical of the Parrot story after the Guile mess. It was
supposed to be a multi-language dynamic runtime as well. But that's a
digression. I don't think you're betting on any particular strategy, just
saying that we should watch Parrot and see how it turns out.

But anyhow, my original suggestion did not start with ctypes at all. From my
point of view, the goal is to express Pythonic constructs in Python (whether
using Ctypes, Pyrex, rctypes, or whaver) where possible rather than
expressing Pythonic constructs in C (PyErr_SetString, PyDict_SetItem, etc.).
Then each runtime can map the Pythonic constructs to their internal model
and use their native FFI strategy (JNI, P/Invoke, libffi) to handle the C
stuff. The actual details of the syntax do not matter to me (though they do
matter!). I also do not care whether it uses a compiler strategy like Pyrex
or a runtime model like ctypes, or a dual-mode strategy like

I accept the current limitations of this technique when it comes to
(especially) C++, and therefore don't promote it as a panacea.

Let me ask a question about our current status. If there were a requirement
to do a simple wrapper library like "crypt" or "getpasswd"...is there any
high level wrapping strategy that you would allow into the standard library?
A ctypes-based module? The C output of a Pyrex compiler? The output of SWIG?

Or is hand-written C code the only thing you want for extensions in the
Python library? Even if the answer is "hand-written C code" it might be nice
to have an explicit statement so that people know in advance. I propose that
if the developer can make the case that a ctypes-based library is more
maintainable than the C code would be, and performance is acceptable for the
problem domain, that the ctypes-based library be acceptable. Would you agree
that that small step is reasonable?

 Paul Prescod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060814/04bca409/attachment.htm 

More information about the Python-3000 mailing list