> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4