> For io, we find this quite manageable indeed, although it is quite more
> complex and quirkier than datetime.

I don't understand how something being "more complex and quirkier," can make it more "manageable."

While admittedly simple, datetime has it's share of quirks.  (See issue 5516, for example.)  Most algorithms are simple, but ord2ymd, for one is quite instructional.  Another example is datetime.fromutc.  If there is a person other than Tim who understands how it works, I have not met him or her yet!

Note that we are not talking about writing something from scratch or bringing a 3rd party module to python library.  Tim's prototype needed almost no changes to pass 2.7 test suit and very few to get ported to 3.x.  The sandbox version is currently at r82218, a dozen small changesets from Tim's version of 6 years ago.

The only remaining task is to make the test suit run tests on both modules.  This is not entirely trivial, but it appears that test_datetime was originally designed to make tested classes replaceable.  Some housecleaning is needed to make it work, but I think it is doable.

I have not checked the C code coverage yet, but python code has 100% coverage as reported by trace module.  (Well, almost - there is exactly one line not covered and it actually contains a bug introduced by pypy!)

In any case, I do intend to maintain datetime.py while I am maintaining datetimemodule.c.  I will use it to prototype new features before implementing them in C.  I think having it in the main tree will increase its visibility and lower the barriers for future contributors.

Let's get back to this discussion after 2.7 is out and more developers can focus on 3.2.