classification
Title: datetime's comparison methods do not return NotImplemented when they should
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 2.7, Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: stutzbach Nosy List: belopolsky, georg.brandl, mark.dickinson, r.david.murray, stutzbach, tim.peters, twb, wsanchez
Priority: normal Keywords:

Created on 2010-02-23 21:27 by wsanchez, last changed 2010-07-31 18:27 by georg.brandl. This issue is now closed.

Files
File name Uploaded Description Edit
datetime_foreigncompare_test.patch twb, 2010-03-01 20:16 test for comparing datetime objects against foreign objects
Messages (15)
msg99954 - (view) Author: Wilfredo Sanchez (wsanchez) Date: 2010-02-23 21:27
datetime's comparison methods do not return NotImplemented when they should.  As a result, if you implement a class that can compare itself with a datetime object, this only works if your class on on the left side of the comparison operation.

This is true for equality as well as ordering operations.
msg99984 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-02-24 01:00
Confirmed on trunk, works as expected in py3k.
msg100269 - (view) Author: Thomas W. Barr (twb) Date: 2010-03-01 20:16
Work-in-progress test for this issue. I'll clean up the test and start work on a patch later tonight.
msg104291 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-04-26 23:57
Thomas, could you write a unit test to go along with your patch?
msg104305 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-04-27 09:38
See issue 5516 for a related issue.
msg104327 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2010-04-27 14:57
Is there a patch with a fix or just a patch with a test.  If the later, maybe someone can remove a patch keyword.
msg104328 - (view) Author: Thomas W. Barr (twb) Date: 2010-04-27 14:58
It's just a test. Finishing the patch completely slipped my mind. I'll work on it later tonight.
msg104329 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-04-27 15:00
You're right.  I asked Thomas the wrong question, and the Keywords and Stage need updating.

Thomas, do you still plan to submit a patch that fixes the problem?
msg104331 - (view) Author: Thomas W. Barr (twb) Date: 2010-04-27 15:01
I'm still reasonably new to the codebase, but I'm certainly going to try to fix the issue.
msg104332 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-04-27 15:04
Great!  If you get stuck or have a question, just ask. :-)
msg104333 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2010-04-27 15:53
Before someone spends more time writing a patch, lets pause and consider whether this is a bug in the first place.

My understanding of the issue is that given

>>> class A(object):
...   def __eq__(self, other):
...    return True
... 

OP expects date(1,1,1) == A() to return True, but instead

>>> date(1,1,1) == A()
False


Note that this problem can be worked around by endowing A with a timetuple attribute:

>>> A.timetuple=1

Now

>>> date(1,1,1) == A()
True

This is a documented feature:

"""
 In order to stop comparison from falling back to the default scheme of comparing object addresses, date comparison normally raises TypeError if the other comparand isn’t also a date object. However, NotImplemented is returned instead if the other comparand has a timetuple() attribute. This hook gives other kinds of date objects a chance at implementing mixed-type comparison. If not, when a date object is compared to an object of a different type, TypeError is raised unless the comparison is == or !=. The latter cases return False or True, respectively.
""" http://docs.python.org/release/2.6.5/library/datetime.html#datetime.date.day (Note 4)

I am adding Tim to the "nosy" list because he appears to be the author of the relevant code.

It is my understanding that this issue can only be regarded as an RFE. Given the fact that 2.x is approaching bug fix only stage (if it is not already there) and the problem is fixed in 3.x, I recommend closing this as "won't fix."

Mark,

No, I don't think this is directly related to issue 5516.
msg104345 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-04-27 18:12
Thanks for pointing that out.  

For what it's worth, if I understand the documentation correctly the goal is to prevent the following misleading comparisons:

date with time
datetime with date
datetime with time
datetime w/ timezone with datetime w/o timezone
time w/ timezone with time w/o timezone

It's unfortunate that it throws a TypeError for all comparisons (unlike complex numbers which only throw a TypeError when comparing with numbers), but I suppose you are right that it's too late to fix this in 2.x.
msg106499 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-05-26 00:52
Any objections to closing this as "won't fix"?
msg106500 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-05-26 01:18
None here.
msg112180 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-07-31 18:27
Closing now.
History
Date User Action Args
2010-07-31 18:27:01georg.brandlsetstatus: pending -> closed

nosy: + georg.brandl
messages: + msg112180

resolution: out of date -> wont fix
2010-05-26 02:25:22belopolskysetstatus: open -> pending
resolution: out of date
2010-05-26 01:18:38stutzbachsetmessages: + msg106500
2010-05-26 00:52:57belopolskysetnosy: + belopolsky, - Alexander.Belopolsky
messages: + msg106499
2010-04-27 18:12:01stutzbachsetmessages: + msg104345
2010-04-27 15:53:33Alexander.Belopolskysetnosy: + tim.peters
messages: + msg104333
2010-04-27 15:39:36stutzbachsetassignee: stutzbach
2010-04-27 15:18:18stutzbachsetkeywords: - patch
stage: test needed -> needs patch
2010-04-27 15:04:21stutzbachsetmessages: + msg104332
2010-04-27 15:01:11twbsetmessages: + msg104331
2010-04-27 15:00:11stutzbachsetmessages: + msg104329
2010-04-27 14:58:55twbsetmessages: + msg104328
2010-04-27 14:57:35Alexander.Belopolskysetnosy: + Alexander.Belopolsky, - belopolsky
messages: + msg104327
2010-04-27 09:38:43mark.dickinsonsetnosy: + belopolsky, mark.dickinson
messages: + msg104305
2010-04-26 23:57:42stutzbachsetmessages: + msg104291
2010-03-01 20:16:47twbsetfiles: + datetime_foreigncompare_test.patch
keywords: + patch
messages: + msg100269
2010-02-26 23:03:01twbsetnosy: + twb
2010-02-25 01:36:13stutzbachsetnosy: + stutzbach
2010-02-24 01:00:52r.david.murraysetpriority: normal
versions: + Python 2.7
nosy: + r.david.murray

messages: + msg99984

stage: test needed
2010-02-23 21:27:36wsanchezcreate