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 PyPy/extcompiler.
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
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
