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 <[EMAIL PROTECTED]> 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 > [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/) _______________________________________________ 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
