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.
There are too many distinct use cases to make this a hard and fast rule. The problem with maintaining many builds is best served by keeping the number of extensions small, period.
BTW, this reminds me of the old idea to move that standard lib into a package, eg. 'python'...
from python import time.
Maybe in Python 3000. In 2.x, I think rearranging the standard library will just cause more upheaval without much benefits.
We should at least reserve such a name RSN so that we don't run into problems later on.
I can guarantee you that that name won't be used as a standard Python module or package name any time soon. If someone creates a 3rd party package or module named 'python' I'd question their sanity. :-)
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)