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

[Guido van Rossum]

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 <greg.ewing at canterbury.ac.nz> 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
> Python-3000 at python.org
> 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/)