I am getting more and more frustrated with the way things are going here lately. At this point I would be more than happy to pass off anything that's assigned to me to other people and just unsubscribe from python-dev. I feel like there are enormous contradictions in the way different changes to Python are being addressed. If you want to take over any of these bugs or patches, feel free: 411881 Use of "except:" in modules 569574 plain text enhancement for cgitb 542562 clean up trace.py 474274 Pure Python strptime() (PEP 42) 541694 whichdb unittest >> I would prefer a time.py module be created to hold Brett's strptime >> function. On import, the last thing it would try doing is to import >> * from _time, which would obliterate Brett's Python version if the >> platform supports strptime(). Guido> That's only a good idea if Brett's Python code has absolutely no Guido> features beyond the C version. I don't understand what you mean. Guido's probably gone by now. Perhaps someone can channel him. I am clearly missing something obvious, but I don't see any support for the argument that having the existing time module call out to a separate Python module makes a lot of sense. (Other than the fact that it comes from the BDFL, of course.) If we put Brett's changes into time.py (I'd argue that initially all we want is strptime(), but can live with the other stuff assuming it's tested - after all, it has to go somewhere), then from _time import * at the bottom, the only thing to be eliminated would be his version of strptime(), and only if the platform libc didn't support it. The Gregorian/Julian date stuff would remain. If you don't want them exposed in time, just prefix them with underscores and don't add them to time.all. The original patch http://python.org/sf/474274 was just about adding strptime() to the time module. All PEP 42 asked for was Add a portable implementation of time.strptime() that works in clearly defined ways on all platforms. All the other stuff is secondary in my mind to making time.strptime() universally available and should be dealt with separately. If performance isn't a big issue (I doubt it will be most of the time), I can see dropping the C version of time.strptime altogether. I still think the best way to add new stuff which is written in Python to the time module is to have time.py be the front-end module and have it import other stuff from a C-based _time module. Skip