(Adding python-3000 back to the CC: list.) On 8/10/06, Paul Prescod <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > [email protected] > > > 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
