I've been thinking about this feature request and am starting to question whether it is necessary.  Usually we need a pure python version when 1) the python module is developed first, with the subsequent C code needing to match, or 2) we expect a porting issue, or 3) for pedagogical purposes (i.e. showing how heaps work).

For example, sets.py preceded setobject.c and ultimately we dropped sets.py.  In the case of heapq.py, it was kept because of its teaching value and because some other implementations like Jython used it.  In other cases like collections.deque, the pure python version is maintained off-line in an ASPN recipe and we may provide a link to it in the docs.

For the datetime module, I don't think we get much value from having pure python and C version in the distribution.  The semantics were worked out a long time ago, the algorithms aren't interesting, and other implementations already have their own conforming versions.  ISTM, a pure python version in our standard distribution would never be run and rarely looked at.  

While it may seem like a cool thing to do, no one has actually requested
this "feature" (I use quotes here because no new functionality is added).  The addition would be mostly harmless but it would increase the maintenance burden (I know because I've actively maintained pure python equivalents for itertools and it has been a PITA).

If this is a step in your development process, I recommend keeping it in a sandbox or publishing it on PyPI.

If we were to invest some efforts in writing pure python equivalents, I would like to see the docs include an equivalent of str.split() whose behavior is difficult to fully and correctly describe in plain English.  In contrast, the availability of a pure python version of datetime wouldn't add much that isn't already covered in the docs.