Re: [Python-Dev] datetime module enhancements
Christian Heimes wrote: From the README.txt pytz brings the Olson tz database into Python. This library allows accurate and cross platform timezone calculations using Python 2.3 or higher. It also solves the issue of ambiguous times at the end of daylight savings, which you can read more about in the Python Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson timezones are supported. This sounds like it may at least be worth a 'See also' in the datetime docs... Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Phillip J. Eby [EMAIL PROTECTED] wrote: At 09:20 PM 3/9/2007 +, Jon Ribbens wrote: If you want the answer to be the entire of that day then you need to alter the datetime module so that, e.g. subtracting 2007-03-08 from 2007-03-09 does not return one day as currently, but returns zero days instead (since of course there is no time between the end of one day and the start of the next day). Unless you decide that subtraction is between days' ends. Or days' beginnings. Either suffices to produce a 1-day result in that case, and is still consistent with viewing days as slices of time. So you're deciding that a 'date' is 'the entire of that day', except when you subtract two of them, when it suddenly means something else? ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 03/09/2007 08:56 PM, Martin v. Löwis wrote: -- Sjoerd Mullender Christian Heimes schrieb: BJörn Lindqvist schrieb: I think it should be a ValueError, given that the programmer is very likely to further use the returned timestamp to for example insert stuff in a database. Unix timestamps are not unambiguously defined for any years other than 1970 to 2038 imho. IIRC the unix timestamp was originally definied as *signed* int with 32bit. Unix time stamps where never defined as being 32bit. That is just an implementation detail. time_t was defined as an int, in second since 1970, and that is all what was defined. Whether or not an int is 32bits depends on the hardware (and the compiler); this was never part of Unix. As I remember, the time() system call on Version 7 Unix on the (16 bit) PDP 11 returned the time as a C long, which on that machine was 32 bits. I just looked at the Version 6 Unix listing, and there too, the time is returned as a 32 bit quantity. I also seem to remember that in the early days, there was no such thing as an unsigned long, so the value was necessarily signed. But I may be misremembering this bit. -- Sjoerd Mullender ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Steven Bethard [EMAIL PROTECTED] wrote: Using the .date() is fine when the year/month/day doesn't match. So the following are fine:: datetime.datetime(2005, 1, 1, 0, 0, 0) datetime.date(2006, 1, 1) datetime.datetime(2007, 1, 1, 0, 0, 0) datetime.date(2006, 1, 1) It's *not* okay to say that a date() is less than, greater than or equal to a datetime() if the year/month/day *does* match. Why not? That only makes sense if you decide that a Python 'date' means 'the entire of that day'. It's not at all clear that that's what a Python 'date' *does* mean. And, as I mentioned before, if you do decide that then what Python currently does when you subtract dates is broken. I just found another case where 'date's pretend to have a time-part of midnight - if you add a date to a timedelta. Add 23 hours to a date and it's unchanged - add 24 and it moves forward a day. If a 'date' really is 'the entire of that day', then adding a timedelta to it which is not an integer multiple of 1 day should either raise an exception, or return some 'time duration' object that doesn't currently exist. The correct temporal relation is During, but Python doesn't have a During operator. During is not the same as less-than, greater-than or equal-to, so all of these should be False:: I think you're assuming the Python datetime module has higher goals than it does. It doesn't have any concept of a duration in time, not unless you couple a 'datetime' with a 'timedelta' yourself. And 'timedelta's are restricted to periods of time that are a fixed number of seconds - i.e. there is no way to indicate a month or a year (although that lack is a whole different argument ;-) ) Your argument is quite correct if you're considering some fancy uber-complicated kitchen-sink-included all-encompassing temporal logic package, but that's not what Python's datetime is, nor frankly is what it should be. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Non implementation dependent access to calling scope
Hello all, I realise that this may be more relevant to Python ideas, in which case feel free to ignore this (and my apologies). I occasionally see code looking (something) like : calling_scope = sys._getframe(1).f_globals['__name__'] This looks and smells like a hack (not least because of the warning in the documentation about _getframe), plus stack frames are an implementation detail so this code is broken on IronPython. This makes me sad. It would be great to have a specified way to obtain [a read only view on (?)] the locals and globals from the calling scope. Perhaps built in functions ? If they were specified then the IronPython guys would have to implement it for us. B-) I realise that this can allow bad some bad programming patterns, but there are times when it can be very useful. All the best, Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Jon Ribbens schrieb: So you're deciding that a 'date' is 'the entire of that day', except when you subtract two of them, when it suddenly means something else? ;-) It makes kinda sense although it looks like a contradiction at first. The common linguistic usage of dates in English and German: On Saturday or On 2007-03-07 is a undefined time anytime on Saturday or the whole Saturday but Saturday and Sunday are a day apart. It feels right to me. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Christian Heimes [EMAIL PROTECTED] wrote: Jon Ribbens schrieb: So you're deciding that a 'date' is 'the entire of that day', except when you subtract two of them, when it suddenly means something else? ;-) It makes kinda sense although it looks like a contradiction at first. The common linguistic usage of dates in English and German: On Saturday or On 2007-03-07 is a undefined time anytime on Saturday or the whole Saturday but Saturday and Sunday are a day apart. It feels right to me. That doesn't help much. English is often very vague about times and dates, but computer programs must be have a defined answer. What do you feel next Tuesday plus 12 hours means? ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Fri, Mar 09, 2007 at 10:10:48PM -0800, Neal Norwitz wrote: We should probably be a lot more aggressive about closing bugs and patches without response. Unfortunately many fall into this category. This question comes up every so often, and after much discussion I think python-dev always converges on leaving bugs open in case some future person finds the information useful. I hope that the Roundup tracker will let us tag such bugs with a 'waiting-for-reporter' tag, and we can then exclude such bugs when looking for ones to fix. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Jon Ribbens schrieb: What do you feel next Tuesday plus 12 hours means? ;-) First thought: It's nonsense! Nobody would say that. ;) Second though: Tuesday noon (12h after the beginning of Tuesday) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non implementation dependent access to calling scope
Martin v. Löwis wrote: Michael Foord schrieb: Hello all, I realise that this may be more relevant to Python ideas, in which case feel free to ignore this (and my apologies). I occasionally see code looking (something) like : calling_scope = sys._getframe(1).f_globals['__name__'] This looks and smells like a hack (not least because of the warning in the documentation about _getframe), Right. This should some helper functions in inspect (which currently aren't there). That would be cool. plus stack frames are an implementation detail so this code is broken on IronPython. I don't think there is much you can do about this. Local variables are also an implementation detail. It would be great to have a specified way to obtain [a read only view on (?)] the locals and globals from the calling scope. Perhaps built in functions ? Please, no builtin functions. :-) If they were specified then the IronPython guys would have to implement it for us. B-) I doubt it. If users of IronPython would want that badly enough, it would be there. sys._getframe has been in CPython for a while, yet it (apparently) is unavailable in IronPython. I would expect that implementing what you propose would similar in effort to implementing sys._getframe. The difference is that IronPython uses .NET stack frames. Because it does a lot of dynamic code generation there are often several .NET stack frames in between what would each Python stack frame. There may be a way to get at the globals for the calling scope in IronPython, I'll ask on the list. Thanks for your reply. Michael I realise that this can allow bad some bad programming patterns, but there are times when it can be very useful. Users who want it can already do it, in CPython. The example you gave isn't even about locals, but the caller's *globals*. I would guess that there is already a way in IronPython to get at these, given that .NET also needs to support stack walks in various places. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Christian Heimes [EMAIL PROTECTED] wrote: What do you feel next Tuesday plus 12 hours means? ;-) First thought: It's nonsense! Nobody would say that. ;) Second though: Tuesday noon (12h after the beginning of Tuesday) I agree with you entirely. Your suggestions correspond to 'throw an exception' and 'return a datetime'. Note that in the second case you are agreeing with me that a date means midnight at the start of that date ;-) Python datetime disagrees with us both. It basically says 'add the timedelta to midnight at the start of the date, then return just the date part of the result'. I assume there is some reason for this surprising behaviour. But this is another example of where datetime is taking a pragmatic approach in an ambiguous situation - exactly as I am suggesting in the situation of comparing a date and a datetime. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 3/9/07, Christian Heimes [EMAIL PROTECTED] wrote: Collin Winter schrieb: I can't say I'm well-versed in the intricacies of date/time issues, but what you say makes sense. This is exactly why I brought this patch up here : ) Oh h...! Seems like I've opened a can of worms here. I only wanted to add some minor enhancements and now it looks like the improvements and the datetime module have to be carefully defined and PEPed. I'm trying to summarize the discussed issues and proposals: * Change the underlying time_t type (Unix timestamp) to use a unsigned 64bit integer even on 32 bit operating systems. * Carefully define the comparison between date and datetime objects. * int(timedelta) and float(timedelta) returns seconds * Add methods to datetime to cast from/to Julian Date Number (also MJD and RJD) * What about moving the C extension to _datetime so we can implement some non time consuming extensions in Python? * What do you think about including PyTz in the Python core? PyTz is really, REALLY useful when one has to deal with time zones. http://pytz.sourceforge.net/ * The dateutil package contains additional features which may prove as useful: http://labix.org/python-dateutil Here's another one for the list, trawled off SF: patch #1118748 (http://python.org/sf/1118748). It proposes to add the ability to add/subtract time and timedelta objects. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unittest enhancement for TestCase classes hierarchies
In my continuing trawl through the SF patch tracker, I came across #1244929 (http://python.org/sf/1244929), which causes TestLoader.loadTestsFromModule() to skip classes whose name starts with an underscore. This addresses the warning in that method's docs: While using a hierarchy of TestCase-derived classes can be convenient in sharing fixtures and helper functions, defining test methods on base classes that are not intended to be instantiated directly does not play well with this method. Doing so, however, can be useful when the fixtures are different and defined in subclasses. Does not play well, in this case, means that your base classes will be picked up against your will if they subclass TestCase. I like the patch and have worked up tests and doc changes for it. Any objections to including this in 2.6? Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest enhancement for TestCase classes hierarchies
On Sat, 10 Mar 2007 09:13:28 -0600, Collin Winter [EMAIL PROTECTED] wrote: In my continuing trawl through the SF patch tracker, I came across #1244929 (http://python.org/sf/1244929), which causes TestLoader.loadTestsFromModule() to skip classes whose name starts with an underscore. This addresses the warning in that method's docs: While using a hierarchy of TestCase-derived classes can be convenient in sharing fixtures and helper functions, defining test methods on base classes that are not intended to be instantiated directly does not play well with this method. Doing so, however, can be useful when the fixtures are different and defined in subclasses. Does not play well, in this case, means that your base classes will be picked up against your will if they subclass TestCase. I like the patch and have worked up tests and doc changes for it. Any objections to including this in 2.6? This use case is what mixins are for. You don't have to include TestCase in your ancestry until you get to a class which you actually want to run tests. The current rule of loading anything that subclasses TestCase is simple and straightforward. Complicating it to provide a feature which is already available through a widely used standard Python idiom doesn't seem worth while. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 3/9/07, Collin Winter [EMAIL PROTECTED] wrote: On the subject of datetime enhancements, I came across an SF patch (#1673403) the other day that proposed making it possible to compare date and datetime objects. One solution that just occurred to me -- and that skirts the issue of choosing an interpretation -- is that, when comparing date and datetime objects, the datetime's .date() method is called and the result of that call is compared to the original date. That is, datetime_obj date_obj is implicitly equivalent to datetime_obj.date() date_obj Seems a ready-made use case for that method. +1 ...and it's a decision that can be made independently of how to add or subtract dates. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Robert Brewer [EMAIL PROTECTED] wrote: One solution that just occurred to me -- and that skirts the issue of choosing an interpretation -- is that, when comparing date and datetime objects, the datetime's .date() method is called and the result of that call is compared to the original date. +1 ...and it's a decision that can be made independently of how to add or subtract dates. I don't like it. It sounds suspiciously like when comparing integers and floats, discard the non-integer portion of the float and then compare as integers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non implementation dependent access to calling scope
Looks like you misunderstand what's going on. sys._getframe() *intentionally* smells like a hack, becase we don't *want* you to feel comfortable using it. Its mere existence may constrain other Python implementations from optimizing the code they generate; it is a compromise to enable those projects that don't care about this to occasionally engage in implementation-specific but useful behavior. On 3/10/07, Michael Foord [EMAIL PROTECTED] wrote: Hello all, I realise that this may be more relevant to Python ideas, in which case feel free to ignore this (and my apologies). I occasionally see code looking (something) like : calling_scope = sys._getframe(1).f_globals['__name__'] This looks and smells like a hack (not least because of the warning in the documentation about _getframe), plus stack frames are an implementation detail so this code is broken on IronPython. This makes me sad. It would be great to have a specified way to obtain [a read only view on (?)] the locals and globals from the calling scope. Perhaps built in functions ? If they were specified then the IronPython guys would have to implement it for us. B-) I realise that this can allow bad some bad programming patterns, but there are times when it can be very useful. All the best, Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 3/10/07, Jon Ribbens [EMAIL PROTECTED] wrote: Steven Bethard [EMAIL PROTECTED] wrote: Using the .date() is fine when the year/month/day doesn't match. So the following are fine:: datetime.datetime(2005, 1, 1, 0, 0, 0) datetime.date(2006, 1, 1) datetime.datetime(2007, 1, 1, 0, 0, 0) datetime.date(2006, 1, 1) It's *not* okay to say that a date() is less than, greater than or equal to a datetime() if the year/month/day *does* match. Why not? That only makes sense if you decide that a Python 'date' means 'the entire of that day'. It's not at all clear that that's what a Python 'date' *does* mean. And, as I mentioned before, if you do decide that then what Python currently does when you subtract dates is broken. No, as Phillip J. Eby pointed out, there's a variety of ways to define subtraction over intervals: (1) Distance between start1 and start2 (2) Distance between start1 and end2 (3) Distance between end1 and start2 (4) Distance between end1 and end2 Options (1) and (4) are consistent with the current implementation. Options (2) and (3) are not. I don't see why the docs can't be explicit about what subtraction means given that there are a number of possible interpretations. I just found another case where 'date's pretend to have a time-part of midnight - if you add a date to a timedelta. Add 23 hours to a date and it's unchanged - add 24 and it moves forward a day. If a 'date' really is 'the entire of that day', then adding a timedelta to it which is not an integer multiple of 1 day should either raise an exception, or return some 'time duration' object that doesn't currently exist. You can draw the analogy here with integer addition:: int(1) + int(.75) 1 int(1) + int(1.25) 2 Though if I had written the datetime module, this would have raised an exception, rather than passing silently. But I suspect that almost no one is adding *hours* to *dates* so I don't particularly care how it behaves, nor do I think that some idiosyncratic behavior in a part of the module no one uses should dictate the behavior in the rest of the module. Your argument is quite correct if you're considering some fancy uber-complicated kitchen-sink-included all-encompassing temporal logic package, but that's not what Python's datetime is, nor frankly is what it should be. I'm not expecting Python's datetime module to handle any complex temporal logic. But boy it would be nice if it didn't *break* basic temporal logic, and that's certainly possible with a very small bit of effort. However, assuming that a date() is a datetime() with a time of midnight will clearly break that logic. I still don't see why my more careful comparison would be bad for any of your code. Could you give an example where it would be bad for all the following to be False:: date(2006, 1, 1) datetime(2006, 1, 1, 0, 0, 0) date(2006, 1, 1) datetime(2006, 1, 1, 0, 0, 0) date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0) even though the following would be True:: date(2006, 1, 1) datetime(2006, 1, 2, 0, 0, 0) date(2006, 1, 1) datetime(2005, 12, 31, 0, 0, 0) ? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Steven Bethard [EMAIL PROTECTED] wrote: I don't see why the docs can't be explicit about what subtraction means given that there are a number of possible interpretations. I don't see why the docs can't be explicit about what comparison means given that there are a number of possible interpretations. You can draw the analogy here with integer addition:: int(1) + int(.75) 1 int(1) + int(1.25) 2 You're making my point for me. An integer (in the abstract sense) *is* the same as a float with a zero fractional part. You're agreeing that datetime treats dates as datetimes with a midnight time part. However, assuming that a date() is a datetime() with a time of midnight will clearly break that logic. Could you please explain how? It doesn't look to me like it breaks anything. I think you're assuming that date means the whole of that day - if so then why do you think that assumption is valid? Using your suggested analogy above, if you consider dates to be ints and datetimes to be floats, then it seems to be that everything makes sense and is logical and coherent. I still don't see why my more careful comparison would be bad for any of your code. Could you give an example where it would be bad for all the following to be False:: date(2006, 1, 1) datetime(2006, 1, 1, 0, 0, 0) date(2006, 1, 1) datetime(2006, 1, 1, 0, 0, 0) date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0) You need me to explain why a b, a b and a == b all being false simultaneously is bad!? What would a != b return? What would cmp(a, b) return? even though the following would be True:: date(2006, 1, 1) datetime(2006, 1, 2, 0, 0, 0) date(2006, 1, 1) datetime(2005, 12, 31, 0, 0, 0) Actually, your suggestion would be much better than the current behaviour, for my uses, even though it's totally illogical. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On 3/10/07, A.M. Kuchling [EMAIL PROTECTED] wrote: On Fri, Mar 09, 2007 at 10:10:48PM -0800, Neal Norwitz wrote: We should probably be a lot more aggressive about closing bugs and patches without response. Unfortunately many fall into this category. This question comes up every so often, and after much discussion I think python-dev always converges on leaving bugs open in case some future person finds the information useful. I was thinking about patches only in this case, not bugs. I hope that the Roundup tracker will let us tag such bugs with a 'waiting-for-reporter' tag, and we can then exclude such bugs when looking for ones to fix. Georg added a comment/feature request for this. Actually, he requested a close on inactivity after some duration if we set a keyword or something like that. Since we are in control of the tracker, we can make it happen if someone cares enough. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] fmod.c
Hi all, Is there any need for Python/fmod.c any more? I can't see how it can be included because there's no test for fmod in the ./configure script and grepping all files in the tree for fmod.c finds nothing except a commented out line in PC/os2vacpp/makefile.omk If it is needed, it needs fixing as it gives the wrong answer for x=0 and y0. Eg: fmod(0, -1) returns 1 rather than 0. (The comment in fmod.c is correct: it should return f such that x = i*y + f for some integer i, st |f| |y| and f has the same sign as x). I'm happy to patch it, but I won't if it would be better just to remove the file. -- Paul Hankin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 3/10/07, Robert Brewer [EMAIL PROTECTED] wrote: On 3/9/07, Collin Winter [EMAIL PROTECTED] wrote: On the subject of datetime enhancements, I came across an SF patch (#1673403) the other day that proposed making it possible to compare date and datetime objects. One solution that just occurred to me -- and that skirts the issue of choosing an interpretation -- is that, when comparing date and datetime objects, the datetime's .date() method is called and the result of that call is compared to the original date. That is, datetime_obj date_obj is implicitly equivalent to datetime_obj.date() date_obj Seems a ready-made use case for that method. +1 ...and it's a decision that can be made independently of how to add or subtract dates. That's what I thought, until Steve Bethard set me straight: http://mail.python.org/pipermail/python-dev/2007-March/071803.html I'm going to defer to him on this. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 3/10/07, Jon Ribbens [EMAIL PROTECTED] wrote: Steven Bethard [EMAIL PROTECTED] wrote: I still don't see why my more careful comparison would be bad for any of your code. Could you give an example where it would be bad for all the following to be False:: date(2006, 1, 1) datetime(2006, 1, 1, 0, 0, 0) date(2006, 1, 1) datetime(2006, 1, 1, 0, 0, 0) date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0) You need me to explain why a b, a b and a == b all being false simultaneously is bad!? Yes. One of the main reasons for having having rich comparisons (__lt__, __eq__, etc.) is to be able to handle partial orderings like the ones we're talking about here. What would a != b return? True. The intervals are not Simultaneous (equal). What would cmp(a, b) return? According to the docs [1], The return value is negative if x y, zero if x == y and strictly positive if x y. Which means that cmp() is undefined in this case (and should probably raise an exception). However, the current behavior is to return 1:: class C(object): ... def __lt__(self, other): ... return False ... def __gt__(self, other): ... return False ... def __eq__(self, other): ... return False ... cmp(C(), C()) 1 Since I don't know too many folks that use cmp() instead of using , or = directly, returning 1 is fine with me. Anyone who has a problem with that should take it up with the cmp() implementation. [1] http://docs.python.org/lib/built-in-funcs.html#l2h-17 even though the following would be True:: date(2006, 1, 1) datetime(2006, 1, 2, 0, 0, 0) date(2006, 1, 1) datetime(2005, 12, 31, 0, 0, 0) Actually, your suggestion would be much better than the current behaviour, for my uses Good. Well at least we're agreed on that part. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 3/10/07, Collin Winter [EMAIL PROTECTED] wrote: On 3/9/07, Christian Heimes [EMAIL PROTECTED] wrote: Collin Winter schrieb: I can't say I'm well-versed in the intricacies of date/time issues, but what you say makes sense. This is exactly why I brought this patch up here : ) Oh h...! Seems like I've opened a can of worms here. I only wanted to add some minor enhancements and now it looks like the improvements and the datetime module have to be carefully defined and PEPed. I'm trying to summarize the discussed issues and proposals: * Change the underlying time_t type (Unix timestamp) to use a unsigned 64bit integer even on 32 bit operating systems. * Carefully define the comparison between date and datetime objects. * int(timedelta) and float(timedelta) returns seconds * Add methods to datetime to cast from/to Julian Date Number (also MJD and RJD) * What about moving the C extension to _datetime so we can implement some non time consuming extensions in Python? * What do you think about including PyTz in the Python core? PyTz is really, REALLY useful when one has to deal with time zones. http://pytz.sourceforge.net/ * The dateutil package contains additional features which may prove as useful: http://labix.org/python-dateutil Here's another one for the list, trawled off SF: patch #1118748 (http://python.org/sf/1118748). It proposes to add the ability to add/subtract time and timedelta objects. And one last patch: #1100942 (http://python.org/sf/1100942), which would add a strptime() constructor for the date and time classes. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest enhancement for TestCase classes hierarchies
On 3/10/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Sat, 10 Mar 2007 09:13:28 -0600, Collin Winter [EMAIL PROTECTED] wrote: In my continuing trawl through the SF patch tracker, I came across #1244929 (http://python.org/sf/1244929), which causes TestLoader.loadTestsFromModule() to skip classes whose name starts with an underscore. This addresses the warning in that method's docs: While using a hierarchy of TestCase-derived classes can be convenient in sharing fixtures and helper functions, defining test methods on base classes that are not intended to be instantiated directly does not play well with this method. Doing so, however, can be useful when the fixtures are different and defined in subclasses. Does not play well, in this case, means that your base classes will be picked up against your will if they subclass TestCase. I like the patch and have worked up tests and doc changes for it. Any objections to including this in 2.6? This use case is what mixins are for. You don't have to include TestCase in your ancestry until you get to a class which you actually want to run tests. The current rule of loading anything that subclasses TestCase is simple and straightforward. Complicating it to provide a feature which is already available through a widely used standard Python idiom doesn't seem worth while. Understood, but I don't like having to keep repeating, yes, this subclass of X is also a TestCase; so is this one, and this one, and this one, etc. Python already ignores _-prefixed names in certain analogous, load-everything-from-a-module situations (from x import *), so I don't see this as being particularly unpythonic. Nor do I see it as all that complicated. Striking the current equivocating, paragraph-long warning from loadTestsFromModule()'s docs and replacing it with Classes whose name starts with an underscore will be ignored seems like a win to me. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Jon Ribbens wrote: So you're deciding that a 'date' is 'the entire of that day', except when you subtract two of them, when it suddenly means something else? ;-) No, you're considering dates to be discrete entities, like integers. You wouldn't use the same reasoning to argue that the difference between two consecutive integers should be 0... would you? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
* Christian Heimes [EMAIL PROTECTED] [2007-03-10 03:58:27 +0100]:
From the README.txt
pytz brings the Olson tz database into Python. This library allows
accurate and cross platform timezone calculations using Python 2.3
or higher. It also solves the issue of ambiguous times at the end
of daylight savings, which you can read more about in the Python
Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson
timezones are supported.
Unfortunately, it would appear that the Olson tz database contains some
rather... uh... confusing data. For example:
pytz.timezone('Africa/Johannesburg')
DstTzInfo 'Africa/Johannesburg' SAST+1:30:00 STD
# SAST is UTC+2 not UTC+1.5
pytz.timezone('Etc/GMT+2')._utcoffset
datetime.timedelta(-1, 79200)
# I thought I asked for GMT+2, not GMT-2
--
mithrandi, i Ainil en-Balandor, a faer Ambar
signature.asc
Description: Digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Tristan Seligmann schrieb:
pytz.timezone('Africa/Johannesburg')
DstTzInfo 'Africa/Johannesburg' SAST+1:30:00 STD
# SAST is UTC+2 not UTC+1.5
pytz.timezone('Etc/GMT+2')._utcoffset
datetime.timedelta(-1, 79200)
# I thought I asked for GMT+2, not GMT-2
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Tristan Seligmann wrote:
Unfortunately, it would appear that the Olson tz database contains some
rather... uh... confusing data. For example:
pytz.timezone('Africa/Johannesburg')
DstTzInfo 'Africa/Johannesburg' SAST+1:30:00 STD
# SAST is UTC+2 not UTC+1.5
The tz of Africa/Johannesburg initially started with an offset of 1h30
before 1903. It looks like a bug in pytz
dt = datetime(2007, 3, 11, 0, 0, 0)
aj = pytz.timezone(Africa/Johannesburg)
aj.utcoffset(dt)
datetime.timedelta(0, 5400)
should be 7200 seconds in 2007
pytz.timezone('Etc/GMT+2')._utcoffset
datetime.timedelta(-1, 79200)
That's another bug. Side note: You shouldn't access the _utcoffset
attribute. The offset may depend on the date.
I notified Stuart about the two issues in his package.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
I see you snipped without response my request to back up your claim that assuming that a date() is a datetime() with a time of midnight will clearly break that logic. Am I to assume you cannot back it up? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Jon Ribbens wrote: What do you feel next Tuesday plus 12 hours means? ;-) I would say it's meaningless. My feeling is that subtracting two dates should give an integer number of days, and that is all you should be allowed to add to a date. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
