Brett Cannon wrote:
> 
> Brett Cannon <brett@python.org> added the comment:
> 
> So yes, cPickle/pickle, cStringIO/StringIO, heapq, etc. are all examples of the approach. One could choose to write the pure Python version first, profile the code, and only write extension code for the hot spots, but obviously that typically doesn't happen.

That's what was done for the datetime module. The pure-Python version
just never made it into the stdlib, AFAIK.

Note that we've just dropped the pure-Python version of the io package
as well, so an approach where we keep the pure-Python prototype
would be a novelty in Python land and should probably be codified
in a PEP.

> As for who maintains it, that's python-dev, just like every other module that is structured like this. When the stdlib gets more of a clear separation from CPython I suspect the other VM maintainers will contribute more.

I'm not sure whether there would be much interest in this. Unless
the core devs are also active in other VM implementations, there's
little motivation to maintain two separate implementations of the
same thing.

Users of CPython will likely only use the C version anyway, so the
pure-Python code would also get little real-life testing.

Perhaps we should open up python-dev to external VM developers
that would have to rely on those pure-Python implementations ?!

> As for PyPy not specifically needing this, that still doesn't solve the problem that Jython and IronPython have with extension code or any other future VM that doesn't try to come up with a solution for extensions.

Both Jython and IronPython could add bridges to CPython extensions
(Jython via the JNI and IronPython via unmanaged code.

Still, you're right in that it's unlikely they will move away from
being pure-Java or pure-C# implementations, so they do have a need
for such pure-Python implementations.