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).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
