One of the arguments put forward against renaming the existing time module to _time (as part of incorporating a pure-Python strptime function) is that it could break some builds. Therefore I'd suggest that it could be a useful principle for any C extension added in the future to the standard library to have an accompanying pure-Python wrapper that would be the one that client code would usually import.
I am for that, but then again I am biased in this situation. =)
But it seems reasonable. I would think everyeone who makes any major contribution of code to Python would much rather code it up in Python then C. It would probably help to get more code accepted since I know I felt a little daunted having to write that callout for strptime.
The only obvious objection I can see to this is a performance hit for having to go through the Python stub to call the C extension. But I just did a very simple test of calling strftime('%c') 25,000 times from time directly and using a Python stub and it was .470 and .490 secs total respectively according to profile.run().
The oher objection I can see is that this would promote coding everything in Python when possible and that might not always be the best solution. Some things should just be coded in C, period. But I think for such situations that the person writing the code would most likely recognize that fact.
Or maybe I am wrong in all of this. I don't know the exact process of how a C extension file gets accepted or what currently leads to an extension file getting a stub is. I would (and I am sure anyone else new to the list) really appreciate someone possibly explaining it to me since I would like to know.