[Python-Dev] strptime recapped

[Guido van Rossum]

>     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/)