I was probably misled by Brett's assertion that 'it's not a matter of "if" but "when" datetime will get a pure Python version.' (msg106498)  It looks like this is not a universally shared opinion.

I am not ready to form a final opinion on datetime.py.  I have ported it to 3.2 to the point where it passes the regression tests, but did not attempt to clean up the code in any way or match C implementation on the level of doc strings and error messages.  I am attaching the diff between PyPy-2.7 and 3.2 port as issue7989-2.7-3.2.diff here. You can find the full source in the sandbox/py3k-datetime at r82083.  I think having a working implementation will help making a decision here.

Here are some random thoughts based on the experience with datetime.py.  

The datetime module have seen very little development in the last six years.  Tracker RFEs and bug reports were languishing for years while people have been ranting about how much better other languages handle date/time than Python.  Python-dev discussions would run into dozens of posts with an inevitable conclusion that the situation is a mess and cannot be fixed.

It is posible that one of the reasons for the current state of affairs was that people with the problem domain expertise did not have C skills and people with the requisite C skills were conditioned by the C approach to time which is an even bigger mess than what we have.  I cannot rule out that if datetime.py was easily available, we would see more patches proposed and more informed discussions about desired features.

Raymond argues that datetime documentation is good enough and python implementation will not add to it.  I disagree.  Consider this passage from tzinfo documentation: "When a datetime object is passed in response to a datetime method, dt.tzinfo is the same object as self. tzinfo methods can rely on this, unless user code calls tzinfo methods directly."  Is this as clear as the following code that makes use of this?

    def fromutc(self, dt):
        ..
        if dt.tzinfo is not self:
            raise ValueError("dt.tzinfo is not self")

Documentation for datetime module is indeed extensive.  The reST file is over 1700 lines long.  This is comparable to about 1900 lines in datetime.py (not counting a long treatise on timezone calculations at the end of the file.)  It may be easier to find an answer in the code than in the documentation.  After all you cannot step through documentation in a debugger.

I am still between -0 and +0 about including datetime.py in the main tree.  For my own development purposes having sandbox version is adequate and maintaining it there is easier than in-tree.  It would be great, however if this discussion would lead to clear guidelines about cases when parallel C and Python implementations are desired and how to maintain such arrangements