I have written the callout to strptime.strptime (strptime is SF patch #474274) as Guido asked. Since that was the current hold-up and the thread has gone dormant, I figured I should summarize the discussion up to this point. 1) what is the need?: The question was raised why this was done. The answer was that since time is just a wrapper around time.h, strptime was not guaranteed since it is not a part of ANSI C. Some ANSI C libraries include it, though (like glibc), because it is so useful. Unfortunately Windows and OS X do not have it. Having it in Python means it is completely portable and no longer reliant on the ANSI C library being kind enough to provide it. 2) strftime dependence: Some people worried about the dependence upon strftime for calculating some info. But since strftime is guaranteed to be there by Python (since it is a part of ANSI C), the dependence is not an issue. 3) locale info for dates: Skip and Guido pointed out that calendar.py now generates the names of the weekdays and months on the fly similar to my solution. So I did go ahead and use it. But Skip pointed out that perhaps we should centralize any code that calculates locale info for dates (calendar.py's names and my code for figuring out format for date/time). I had suggested adding it to the locale module and Guido responded that Martin had to ok that. Martin hasn't responded to that idea. 4) location of strptime: Skip asked why Guido was having me write the callout patch to timemodule.c. He wondered why Lib/time.py wasn't just created holding my code and then renaming timemodule.c to _timemodule.c and importing it at the end of time.py. No response has been given thus far for that. I also suggested a possible time2 where things like strptime, my helper fxns (calculate the Julian date from the Gregorian date, etc.), and things such as naivetime could be kept. That would allow time to stay as a straight wrapper to time.h while all bonus code gets relegated to time2. Guido said it might be a good idea but would have to wait until he got back from vacation. That pretty much sums up everything to this point; hope I got it right and didn't miss anything. -Brett C.
time2 might be a good place to include the nifty Reingold-Dershowitz "rata die" date numbering; it can be converted back and forth a vast number of widely used calendars: Julian, Gregorian, Hebrew, old and new Hindu, Chinese (given enough floating-point accuracy), Astronomical Julian, and several others. Generally, "Julian" dates are really just the day number within a given year; this is a simple special case of the more general (and more useful) approach that R-D use. See http://emr.cs.iit.edu/home/reingold/calendar-book/index.shtml for more information. --- Brett Cannon <bac@OCF.Berkeley.EDU> wrote:
I have written the callout to strptime.strptime (strptime is SF patch #474274) as Guido asked. Since that was the current hold-up and the thread has gone dormant, I figured I should summarize the discussion up to this point.
1) what is the need?: The question was raised why this was done. The answer was that since time is just a wrapper around time.h, strptime was not guaranteed since it is not a part of ANSI C. Some ANSI C libraries include it, though (like glibc), because it is so useful. Unfortunately Windows and OS X do not have it. Having it in Python means it is completely portable and no longer reliant on the ANSI C library being kind enough to provide it.
2) strftime dependence: Some people worried about the dependence upon strftime for calculating some info. But since strftime is guaranteed to be there by Python (since it is a part of ANSI C), the dependence is not an issue.
3) locale info for dates: Skip and Guido pointed out that calendar.py now generates the names of the weekdays and months on the fly similar to my solution. So I did go ahead and use it. But Skip pointed out that perhaps we should centralize any code that calculates locale info for dates (calendar.py's names and my code for figuring out format for date/time). I had suggested adding it to the locale module and Guido responded that Martin had to ok that. Martin hasn't responded to that idea.
4) location of strptime: Skip asked why Guido was having me write the callout patch to timemodule.c. He wondered why Lib/time.py wasn't just created holding my code and then renaming timemodule.c to _timemodule.c and importing it at the end of time.py. No response has been given thus far for that.
I also suggested a possible time2 where things like strptime, my helper fxns (calculate the Julian date from the Gregorian date, etc.), and things such as naivetime could be kept. That would allow time to stay as a straight wrapper to time.h while all bonus code gets relegated to time2. Guido said it might be a good idea but would have to wait until he got back from vacation.
That pretty much sums up everything to this point; hope I got it right and didn't miss anything.
-Brett C.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
===== -- S. Lott, CCP :-{) S_LOTT@YAHOO.COM http://www.mindspring.com/~slott1 Buccaneer #468: KaDiMa Macintosh user: drinking upstream from the herd. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Brett> 4) location of strptime: Brett> Skip asked why Guido was having me write the callout patch to Brett> timemodule.c. He wondered why Lib/time.py wasn't just created Brett> holding my code and then renaming timemodule.c to _timemodule.c Brett> and importing it at the end of time.py. No response has been Brett> given thus far for that. This is what's keeping me from going further. I did run the test suite against the latest version with no problem. I think making the current time module call out to a new strptime module is the wrong way to do things, especially given past practice (socket/_socket, string/strop, etc). I would prefer a time.py module be created to hold Brett's strptime function. On import, the last thing it would try doing is to import * from _time, which would obliterate Brett's Python version if the platform supports strptime(). Brett> I also suggested a possible time2 where things like strptime, my Brett> helper fxns (calculate the Julian date from the Gregorian date, Brett> etc.), and things such as naivetime could be kept. That's well beyond the scope of this patch. I'd rather not address it at this point (at least not on this thread). I'd prefer to just focus on how best to add strptime() to platforms without a libc version. Skip
This is what's keeping me from going further. I did run the test suite against the latest version with no problem. I think making the current time module call out to a new strptime module is the wrong way to do things, especially given past practice (socket/_socket, string/strop, etc). I would prefer a time.py module be created to hold Brett's strptime function. On import, the last thing it would try doing is to import * from _time, which would obliterate Brett's Python version if the platform supports strptime().
That's only a good idea if Brett's Python code has absolutely no features beyond the C version. I'm -0 on the time.py idea -- it seems it would churn things around more than absolutely necessary. But you're right about the socket precedent. --Guido van Rossum (home page: http://www.python.org/~guido/)
I am getting more and more frustrated with the way things are going here lately. At this point I would be more than happy to pass off anything that's assigned to me to other people and just unsubscribe from python-dev. I feel like there are enormous contradictions in the way different changes to Python are being addressed. If you want to take over any of these bugs or patches, feel free: 411881 Use of "except:" in modules 569574 plain text enhancement for cgitb 542562 clean up trace.py 474274 Pure Python strptime() (PEP 42) 541694 whichdb unittest >> I would prefer a time.py module be created to hold Brett's strptime >> function. On import, the last thing it would try doing is to import >> * from _time, which would obliterate Brett's Python version if the >> platform supports strptime(). Guido> That's only a good idea if Brett's Python code has absolutely no Guido> features beyond the C version. I don't understand what you mean. Guido's probably gone by now. Perhaps someone can channel him. I am clearly missing something obvious, but I don't see any support for the argument that having the existing time module call out to a separate Python module makes a lot of sense. (Other than the fact that it comes from the BDFL, of course.) 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. The original patch http://python.org/sf/474274 was just about adding strptime() to the time module. All PEP 42 asked for was Add a portable implementation of time.strptime() that works in clearly defined ways on all platforms. All the other stuff is secondary in my mind to making time.strptime() universally available and should be dealt with separately. 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. Skip
(I'm still here, for maybe another hour.)
I am getting more and more frustrated with the way things are going here lately. At this point I would be more than happy to pass off anything that's assigned to me to other people and just unsubscribe from python-dev. I feel like there are enormous contradictions in the way different changes to Python are being addressed.
This sounds like a reference to something I've said but I don't get it.
If you want to take over any of these bugs or patches, feel free:
411881 Use of "except:" in modules 569574 plain text enhancement for cgitb 542562 clean up trace.py 474274 Pure Python strptime() (PEP 42) 541694 whichdb unittest
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
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/)
After reading all the email up to this point, [Guido van Rossum]
[Skip]
[snip]
* 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. :-)
I have to agree with Guido on this one. It might only make sense to people who come from C, but it has always been named this in Python. If the decision is made to go with another module for this code, though, then that is a different story.
* 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
I think you're right. I wrote this code originally after my last final ever in college as an undergraduate and so I was just more interested in relaxing and churning out some good code then being overtly proper in fxn naming. =) I will go through and read the Python coding style PEP and clean up my code. [snip] [Big discussion on whether a new module in Lib or just the callout to my Python code from timemodule.c ensued that is beyond my comment since I am so new to this list]
Yes, holding off until I have the time to work on datetime and review Brett's patch seems wise. Apologies for Brett.
It's quite fine with me. I want to see this done right just like everyone else who cares about Python's development. Personally, I am just ecstatic that I am getting to help out in some way. I feel more like a giddy little kid who is helping out some grown-ups with some important project than a recent college graduate. =) Enjoy your vacation, Guido. And don't leave us, Skip! I know I have greatly appreciated your help both on my patch and your input into all the other threads that have been going on as late here. -Brett C.
[Skip Montanaro]
... * Is strptime even the right name for it? I doubt it. Only us C-heads would think that was a good name.
Given that we're stuck with strftime for date->string, strptime for string->date is better than just about anything else ('f' for 'format', 'p' for 'parse').
* If you create a strptime (or timeparse or parsedate) module should it really have exposed functions named julianFirst, julianToGreg or gregToJulian?
No, and definitely not at first. Stick to the original request and this will be sooooo much easier to resolve. As you put it earlier, All PEP 42 asked for was Add a portable implementation of time.strptime() that works in clearly defined ways on all platforms. Cool! Let's do just that much to start, and don't take it as "a reason" to rename the time module either (it really is trivial to add another .py file to Lib! give the name a leading underscore if you want to imply it's a helper for something else).
[Tim Peters]
[Skip Montanaro] [snip]
Cool! Let's do just that much to start, and don't take it as "a reason" to rename the time module either (it really is trivial to add another .py file to Lib! give the name a leading underscore if you want to imply it's a helper for something else).
Sounds good to me. Perhaps this is the best solution for Python 2.3 (goes beta mid-July, right?). If we do this should we leave access to the C version of strptime, or move all calls over to my code? Personally, I say leave it since then any possible differences people might have with their implementation of strptime compared to mine won't affect them. This is not saying that I think there is, though; I have done my best to make sure there is not a deviance. There is also a noticeable performace difference between my implementation and the C version. I have tried to address the best I could by making locale discovery lazy and being able to have the re object used for a format string be returned so as to use that instead of having to recalculate it, but there is still going to be a difference. So basically, I am agreeing with Tim that my module should just be added as Lib/_strptime.py and my callout should just be added to timemodule.c. I will clean up the naming of my helper fxns and add __all__ to only contain strptime to keep it simple. That will get this in for 2.3 and lets this discussion of where time fxns, data types, etc. are going to be in Python. Who would of thought little old me would spark a Timbot response. =) -Brett C.
21/06/2002 10:27:22 PM, Steven Lott <s_lott@yahoo.com> wrote:
Generally, "Julian" dates are really just the day number within a given year; this is a simple special case of the more general (and more useful) approach that R-D use.
See http://emr.cs.iit.edu/home/reingold/calendar-book/index.shtml
for more information.
AFAICT from perusing their book, R-D use the term "julian-date" to mean a tuple (year, month, day) in the Julian calendar. The International Astro. Union uses "Julian date" to mean an instant in time measured in days (and fraction therof) since noon on 1 January -4712 (Julian ("proleptic") calendar). See for example http://maia.usno.navy.mil/iauc19/iaures.html#B1 A "Julian day number" (or "JDN") is generally used to mean an ordinal day number counting day 0 as Julian_calendar(-4712, 1, 1) as above. Some folks use JDN to include the IAU's instant-in-time. Some folks use "julian day" to mean a day within a year (range 0-365 *or* 1-366 (all inclusive)). This terminology IMO should be severely deprecated. The concept is best described as something like "day of year", with a specification of the origin (0 or 1) when appropriate. It is not clear from the first of your sentences quoted above exactly what you are calling a "Julian date": (a) the tuple (given_year, day_of_year) with calendar not specified or (b) just day_of_year. However either answer seems IMO to be an inappropriate addition to the terminology confusion. Cheers, John
Thanks for the amplification - that was precisely my point. When proposing that strptime() parse "Julian" dates, some more precise definition of Julian is required. --- John Machin <sjmachin@lexicon.net> wrote:
21/06/2002 10:27:22 PM, Steven Lott <s_lott@yahoo.com> wrote:
Generally, "Julian" dates are really just the day number
within
a given year; this is a simple special case of the more general (and more useful) approach that R-D use.
See http://emr.cs.iit.edu/home/reingold/calendar-book/index.shtml
for more information.
AFAICT from perusing their book, R-D use the term "julian-date" to mean a tuple (year, month, day) in the Julian calendar. The International Astro. Union uses "Julian date" to mean an instant in time measured in days (and fraction therof) since noon on 1 January -4712 (Julian ("proleptic") calendar). See for example http://maia.usno.navy.mil/iauc19/iaures.html#B1
A "Julian day number" (or "JDN") is generally used to mean an ordinal day number counting day 0 as Julian_calendar(-4712, 1, 1) as above. Some folks use JDN to include the IAU's instant-in-time.
Some folks use "julian day" to mean a day within a year (range 0-365 *or* 1-366 (all inclusive)). This terminology IMO should be severely deprecated. The concept is best described as something like "day of year", with a specification of the origin (0 or 1) when appropriate.
It is not clear from the first of your sentences quoted above exactly what you are calling a "Julian date": (a) the tuple (given_year, day_of_year) with calendar not specified or (b) just day_of_year. However either answer seems IMO to be an inappropriate addition to the terminology confusion.
Cheers, John
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
===== -- S. Lott, CCP :-{) S_LOTT@YAHOO.COM http://www.mindspring.com/~slott1 Buccaneer #468: KaDiMa Macintosh user: drinking upstream from the herd. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
[Steven Lott]
Thanks for the amplification - that was precisely my point. When proposing that strptime() parse "Julian" dates, some more precise definition of Julian is required.
[snip] strptime just follows strftime's definition of a Julian day which is the number of days since Jan. 1 of the year. It is out of my hands in terms of definition of what type of Julian info strptime parses since I just follow the formats for strftime. But when Guido implements the new datetime type this argument will change since both versions that he is considering do not include any Julian days or dates. There could be fxns, though (mine could actually be used), that do calculate various Julian values and those can be abundantly clear on what they return. -Brett
participants (6)
-
Brett Cannon -
Guido van Rossum -
John Machin -
Skip Montanaro -
Steven Lott -
Tim Peters