Re: [Python-ideas] bool(datetime.time(0, 0)) vs missing data
On Wed, May 9, 2012 at 2:07 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
... Does midnight warrant any special ...
Why do you think that 0 represents midnight? *Because* it is zero, it will often be used as a default for missing data.
The cyclic groups Z/n have a zero element, so *something* has to be effectively zero; start of day is as reasonable as anything else. Or are you just saying that there aren't *any* meaningful binary operators on hour-of-the-day, beyond __eq__ and __ne__? Practicality Beats Purity suggests that at least comparisons should work consistently, so that time-of-day can be consistently ordered, and that requires a least element. (You could make it noon, or mean sunrise, or actual sundown at a certain monument, but you do need one.)
Besides, we have a special value called None exactly for the purpose of representing missing data.
Not really at the moment, since datetime.time doesn't accept it as an argument, and itself uses 0 for missing data. That could *probably* be fixed in an upwards compatible way, but you would still have to special case how missing-data times should compare to current class instances. # Should they ever be equal? # If not, mixing types is a problem. time(hour, min, sec, microsecond) == Time(hour, min, sec, microsecond) ? # Should microseconds be required? # If not, mixing types is a problem. time(hour, min, sec, microsecond=0) == Time(hour, min, sec, microsecond=None) ? # Should even hours be required? # If so, how much precision is logically required? time(hour=0, min=0, sec=0, microsecond=0) == Time(hour=None, min=None, sec=None, microsecond=None) ? # datetime.time already skips the date. # Can hours be skipped too, to indicate "every hour on the hour"? Time(hour=None, min=0, sec=0, microsecond=0) ? # Should missing data never match, match 0, or match anything (the "on the hour" case) time(hour=7, min=15, sec=0, microsecond=0) == Time(hour=None, min=15, sec=0, microsecond=0) ? -jJ
On Wed, 9 May 2012 12:38:19 -0400 Jim Jewett <jimjjewett@gmail.com> wrote:
There aren't indeed. __eq__ and __ne__ don't produce a time result, so they can't be used as a basis for a group. Hence, the notion of a "zero" which you invoked is undefined here.
Sure, so what? Let's say you are creating a day-of-week class with 7 possible instances, and you make them orderable. Does it mean that the least of them (say, Monday or Sunday) should evaluate to false?
That's bogus. int() doesn't take None as an argument, yet None is often used to indicate a missing integer argument in other APIs. This fact is true for most types under the sun. You are just inventing non-existing contraints. Regards Antoine.
On Wed, May 9, 2012 at 12:38 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
Times are not a group -- there's no addition or multiplication operator among times. They only add against timedeltas, and timedeltas are the ones that need a 0 in order for that to work properly in some sense (since the result is a time). -- Devin
Egh, maybe I should elaborate. On Wed, May 9, 2012 at 1:10 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
In some system with addition, you generally want an "identity element" (called 0), such that for every x, 0 + x = x. + is only defined with times for timedeltas, not with times and other times. It doesn't make sense to add 3 'oclock to 5 'oclock. So if we're talking about some 0 such that 0 + x = x, either 0 is the time and x is the timedelta, or 0 is the timedelta and x is the time. It doesn't make sense for the zero to be with the times, since the result of addition with a timedelta shouldn't be a timedelta. There is no time such that time + x = x for any timedelta x. This basically means that there is _no time that makes sense as a "zero"_. At all. You can pick some arbitrary one and call it zero, but it isn't zero in an arithmetical sense. On the other hand, there definitely is a zero timedelta: x + timedelta(0) = x for every time x. -- Devin
On Wed, May 9, 2012 at 1:10 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
Times are not a group -- there's no addition or multiplication operator among times. They only add against timedeltas, ...
No, they don't. There is really very little that you can do with detached time objects. While they have the tzinfo, with any timezone that observes DST it is useless. That's the main reason I am so skeptical about any ideas about improving the time type. Users should just learn to avoid using it and use full datetime instead.
On Wed, 9 May 2012 12:38:19 -0400 Jim Jewett <jimjjewett@gmail.com> wrote:
There aren't indeed. __eq__ and __ne__ don't produce a time result, so they can't be used as a basis for a group. Hence, the notion of a "zero" which you invoked is undefined here.
Sure, so what? Let's say you are creating a day-of-week class with 7 possible instances, and you make them orderable. Does it mean that the least of them (say, Monday or Sunday) should evaluate to false?
That's bogus. int() doesn't take None as an argument, yet None is often used to indicate a missing integer argument in other APIs. This fact is true for most types under the sun. You are just inventing non-existing contraints. Regards Antoine.
On Wed, May 9, 2012 at 12:38 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
Times are not a group -- there's no addition or multiplication operator among times. They only add against timedeltas, and timedeltas are the ones that need a 0 in order for that to work properly in some sense (since the result is a time). -- Devin
Egh, maybe I should elaborate. On Wed, May 9, 2012 at 1:10 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
In some system with addition, you generally want an "identity element" (called 0), such that for every x, 0 + x = x. + is only defined with times for timedeltas, not with times and other times. It doesn't make sense to add 3 'oclock to 5 'oclock. So if we're talking about some 0 such that 0 + x = x, either 0 is the time and x is the timedelta, or 0 is the timedelta and x is the time. It doesn't make sense for the zero to be with the times, since the result of addition with a timedelta shouldn't be a timedelta. There is no time such that time + x = x for any timedelta x. This basically means that there is _no time that makes sense as a "zero"_. At all. You can pick some arbitrary one and call it zero, but it isn't zero in an arithmetical sense. On the other hand, there definitely is a zero timedelta: x + timedelta(0) = x for every time x. -- Devin
On Wed, May 9, 2012 at 1:10 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
Times are not a group -- there's no addition or multiplication operator among times. They only add against timedeltas, ...
No, they don't. There is really very little that you can do with detached time objects. While they have the tzinfo, with any timezone that observes DST it is useless. That's the main reason I am so skeptical about any ideas about improving the time type. Users should just learn to avoid using it and use full datetime instead.
participants (5)
-
Alexander Belopolsky -
Antoine Pitrou -
Devin Jeanpierre -
Greg Ewing -
Jim Jewett