> My understanding is that the desire to have pure 
> python versions of standard library modules is 
> to decouple the standard library from dependency 
> on CPython as far as practical.

That is a bit of a broad brush.  I do not know
of an approved project to give all C modules
a pure python equivalent (in fact modules like
pickle presented a long-term maintenance problem
in that the two versions differed and modules
like sets.py were dropped entirelly).

Looking at svn.python.org/view/python/trunk/Modules/
I see some which are good candidates and many which
aren't.  We need to show judgment on which one to do
and recognize that maintaining dual code is a 
heavy maintenance burden and only do so where
there is a clear value add.

In my judgment, something like str.split() would
benefit quite a bit from a pure python equivalent
because its spec is somewhat opaque and hidden
in C code and because both docs and the test 
coverage are incomplete.

In contrast, I believe that dual code for datetime 
is a net loss.  There is a reason that Uncle Timmy 
didn't put it in in the first place.  

Also, for those who haven't tried it before, it is
not always easy to get good pure python equivalents
(i.e. C iterators check their arguments when first
called and Python versions do their argument checking
when next() is first called; C functions sometimes
do interesting keyword argument handling that cannot be 
done in pure python; and pure python versions differ
in their tracebacks).  Also, it's easy to make a mistake
and misspecify the pure python version.  You're relying
on the test suite to catch all semantic differences.