[issue8005] datetime's comparison methods do not return NotImplemented when they should

Alexander Belopolsky report at bugs.python.org
Tue Apr 27 17:53:34 CEST 2010

Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

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()

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

>>> A.timetuple=1


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

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."


No, I don't think this is directly related to issue 5516.

nosy: +tim_one

Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list