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

[Guido van Rossum]

(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/)