Guido> I guess my objection (of -0 strength) against renaming time to Guido> _time is that you'd have to fix a dozen or so build recipes for Guido> all sorts of exotic platforms. The last time something like this Guido> was done (for new, a much less popular module than time) the Guido> initial change set broke the Windows build, and I think I saw Mac Guido> build changes for this issue checked in today or yesterday. Okay, I can understand that issue. Still, that is a mere ripple compared to the longer term ramifications of taking a wrong turn by adding a strptime module that might turn out to be more-or-less an orphan. You have to consider: * Is strptime even the right name for it? I doubt it. Only us C-heads would think that was a good name. * If you create a strptime (or timeparse or parsedate) module should it really have exposed functions named julianFirst, julianToGreg or gregToJulian? Ignore the studly caps issue (sorry Brett, I don't think they fit in with normal naming practice in the Python core library) and just consider the functionality. Guido> We can avoid all that if the time module calls out to Guido> strptime.py. But it seems to me that it would be an even bigger step to add a new module to Lib, which, as it now sits, would probably only provide a single useful function. >> 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. Guido> It's not that I don't want to expose them. I haven't seen them, so I Guido> don't know how useful they are. Guido> However (as I have tried to point out a few times now in response Guido> to proposed changes to calendar.py) I plan to introduce the new Guido> datetime type that's currently living in Guido> nondist/sandbox/datetime/, either the Python version or the C Guido> version if we find time to finish it. Right. Which is another reason I think we shouldn't just plop a strptime module into Lib. There is more going on with time issues than just adding time.strptime(). Creating a Python-based time module seems less intrusive to me at the user level than creating new module you will wind up supporting for a long time. >> 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. Guido> I hope I can dissuade you from this. Likewise. ;-) It's clear that there is a lot of semi-related stuff going on related to timekeeping and time calculations. Maybe the best course is simply to hold off on Brett's patch for the time being and consider it in the context of the all the other stuff (your datetime object, Brett's Gregorian/Julian functions, etc). Skip