[Python-3000] Ctypes as cross-interpreter C calling interface (original) (raw)

Guido van Rossum guido at python.org
Fri Aug 11 01:17:52 CEST 2006

(Adding python-3000 back to the CC: list.)

On 8/10/06, Paul Prescod <paul at prescod.net> wrote:

The only reason to tie it to Py3K is because Py3K is breaking APIs anyhow. It will be in the overlap period between Py3K and Py2x that the need for an abstraction will be most acute. Otherwise extensions will probably end up with a lot of #ifdef py3k #else etc.

It isn't clear how ambitious or not this is until we drill in. For example, if pure "ctypes" is sufficiently efficient for 90% of all extensions, then moving in this direction for Py3K might require nothing more than a declaration from you that new extensions should be written using ctypes instead of the PyObject APIs unless there is a very good reason. After all, people will take their cue from you as to what sort of coding convention is appropriate for the standard library. Is this first step doable? Just a declaration that (with a few exceptions) ctypes is preferable to C code for new extensions? But if that's totally unreasonable because ctypes is seldom performant enough then the project gets more ambitious because it would have to pull in extcompiler...

I don't know enough about ctypes, but assuming I have a reason to write an extension in C (e.g. Tkinter, which uses the Tcl/Tk API), how to I use ctypes to call things like PyDict_GetItem() or PyErr_SetString()?

--Guido

On 8/10/06, Guido van Rossum <guido at python.org> wrote: > 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 > paralysis. > > --Guido > > 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[1]) 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 > > > > [1] > > http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html > > > > > > > > _> > ________________________ > > Python-3000 mailing list > > Python-3000 at python.org > > http://mail.python.org/mailman/listinfo/python-3000 > > Unsubscribe: > > http://mail.python.org/mailman/options/python-3000/guido%40python.org > > > > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) >

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list