Alexander Belopolsky <alexander.belopol...@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() 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. ---------- nosy: +tim_one _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8005> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
