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

[Guido van Rossum]

On 12/19/06, Nick Coghlan <ncoghlan at gmail.com> 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/)