[Python-Dev] strptime recapped

[Skip Montanaro]

    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