[Python-3000] Modules with Dual Python/C Implementations

Nick Coghlan ncoghlan at gmail.com
Tue Dec 19 10:27:13 CET 2006

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


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-3000 mailing list