Re: [Python-ideas] [Python-Dev] datetime module enhancements

[Moving to python-ideas...] On 3/9/07, Steven Bethard <steven.bethard@gmail.com> wrote on python-dev:
It might be neat to add a __contains__ method to date() objects so that "datetime(2007, 1, 1, 0, 0, 0) in date(2007, 1, 1)" would be True. This would seem to fulfill the During operator. Collin Winter

Collin Winter wrote:
Yeah, I had the same idea: http://permalink.gmane.org/gmane.comp.python.devel/86828 In my opinion the comparison operations for date and datetime object should be defined as: datetime before date: < -----------------------
datetime during date: in ------------------------
datetime after date: > ----------------------
datetime <= date and datetime => date should raise a TypeError. The result is ambiguous. A date with time is never equal to a date. Christian

On 3/12/07, Christian Heimes <lists@cheimes.de> wrote:
datetime <= date and datetime => date should raise a TypeError. The result is ambiguous. A date with time is never equal to a date.
As a practical matter, sorting uses <= I would be somewhat annoyed if dt < d were True, but when I tried to sort them, dt <= d raised a TypeError. It would be OK with me to raise an error (ValueError?) on "dt <= d" if "dt in d". Others might feel differently, and prefer to always get the TypeError -- which is probably why dt<t doesn't already do the obvious thing. -jJ

Jim Jewett wrote:
Seems to me that given all the conflicting behaviours peole want this to have in different circumstances, refusing to compare dates and datetimes is the right thing to do. All the use cases I've seen here for comparing them are easily accommodated by either extracting a date from the datetime to compare with the other date, or deriving a datetime from the date with whatever default time part you want. EIBTI. -- Greg

On 3/12/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Right. A lot of thought went into this when the original design was done. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 3/12/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The "conflicting behaviors" are really just at the boundaries, and the only reason they're "conflicting" is because people don't really seem to know yet what they need. This is probably an indication that an appropriately extended datetime module should be distributed as a third-party module for a while first... 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

Collin Winter wrote:
Yeah, I had the same idea: http://permalink.gmane.org/gmane.comp.python.devel/86828 In my opinion the comparison operations for date and datetime object should be defined as: datetime before date: < -----------------------
datetime during date: in ------------------------
datetime after date: > ----------------------
datetime <= date and datetime => date should raise a TypeError. The result is ambiguous. A date with time is never equal to a date. Christian

On 3/12/07, Christian Heimes <lists@cheimes.de> wrote:
datetime <= date and datetime => date should raise a TypeError. The result is ambiguous. A date with time is never equal to a date.
As a practical matter, sorting uses <= I would be somewhat annoyed if dt < d were True, but when I tried to sort them, dt <= d raised a TypeError. It would be OK with me to raise an error (ValueError?) on "dt <= d" if "dt in d". Others might feel differently, and prefer to always get the TypeError -- which is probably why dt<t doesn't already do the obvious thing. -jJ

Jim Jewett wrote:
Seems to me that given all the conflicting behaviours peole want this to have in different circumstances, refusing to compare dates and datetimes is the right thing to do. All the use cases I've seen here for comparing them are easily accommodated by either extracting a date from the datetime to compare with the other date, or deriving a datetime from the date with whatever default time part you want. EIBTI. -- Greg

On 3/12/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Right. A lot of thought went into this when the original design was done. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 3/12/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The "conflicting behaviors" are really just at the boundaries, and the only reason they're "conflicting" is because people don't really seem to know yet what they need. This is probably an indication that an appropriately extended datetime module should be distributed as a third-party module for a while first... 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
participants (6)
-
Christian Heimes
-
Collin Winter
-
Greg Ewing
-
Guido van Rossum
-
Jim Jewett
-
Steven Bethard