[Python-3000] Modules with Dual Python/C Implementations (original) (raw)

Guido van Rossum guido at python.org
Tue Dec 19 02:37:22 CET 2006

I think a reasonable solution here is to make the C version an optional implementation detail of the Python version, such as was done for the heapq module already (the C version is _heapq and automatically imported by heapq.py if it exists). If this requires that some of the C modules need to be upgraded to be more feature compatible with the Python versions, so be it -- that would be a nice summer-of-code project for someone. Also, the specific problem with StringIO (that the .py version supports Unicode while the C version doesn't) will hopefully go away with the string unification.

--Guido

On 12/12/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

Thomas Wouters wrote:

> Except, of course, when the Python versions has features the C version > does not (thinking specifically of StringIO and unicode here.) Yes, I'm assuming the case where the Python and C versions are functionally equivalent. If not, then either the extra features of the Python version should be ported to the C version first, or the features should be partitioned into two non-overlapping modules. Having two almost-but-not-quite identically functioning modules is not a good idea. -- Greg

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

More information about the Python-3000 mailing list