Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, mark.dickinson, r.david.murray, stutzbach, tim.peters, twb, wsanchez
Date 2010-04-27.15:53:32
SpamBayes Score 4.32682e-12
Marked as misclassified No
Message-id <>
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.
""" (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.
Date User Action Args
2010-04-27 15:53:35Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, tim.peters, mark.dickinson, wsanchez, stutzbach, r.david.murray, twb
2010-04-27 15:53:34Alexander.Belopolskysetmessageid: <>
2010-04-27 15:53:33Alexander.Belopolskylinkissue8005 messages
2010-04-27 15:53:32Alexander.Belopolskycreate