On 12/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > 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. > > Note that this approach has the additional benefit of being friendlier to a > hybrid implementation where only some of the module functionality is provided > by the C version (ala functools/_functools - one of the key goals for partial > is to be faster than the equivalent function, so it's in C, while the rest of > that module isn't likely to be performance critical, so it's left in Python).
*And* it's friendlier to Jython/IronPython/PyPy etc. Everybody wins. I suspect this can be done in 2.6 even. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
