Guido> I guess my objection (of -0 strength) against renaming Guido> time to _time is that you'd have to fix a dozen or so Guido> build recipes for all sorts of exotic platforms. The Guido> last time something like this was done (for new, a much Guido> less popular module than time) the initial change set Guido> broke the Windows build, and I think I saw Mac build Guido> changes for this issue checked in today or yesterday.
[Skip]
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.
It's already called strptime in the time module. :-)
* 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.
I think it shouldn't, see my argument about the datetime type.
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.
IMO a new module in Lib is a much smaller step than renaming an existing built-in module. New modules get added all the time.
>> 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 Guido> seen them, so I don't know how useful they are.
Guido> However (as I have tried to point out a few times now in Guido> response to proposed changes to calendar.py) I plan to Guido> introduce the new datetime type that's currently living Guido> in nondist/sandbox/datetime/, either the Python version Guido> or the C 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.
I guess we just disagree. Th datetime type does *not* have parsing capability, so we still need a strptime.
>> 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).
Yes, holding off until I have the time to work on datetime and review Brett's patch seems wise. Apologies for Brett. --Guido van Rossum (home page: http://www.python.org/~guido/)