Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
Upon further reflection I am -1 on this patch. First, as implemented this patch changes behavior of an explicit invocation of date.__eq__. The patch proposes to remove the following tests: - # Neverthelss, comparison should work with the base-class (date) - # projection if use of a date method is forced. - self.assert_(as_date.__eq__(as_datetime)) - different_day = (as_date.day + 1) % 20 + 1 - self.assert_(not as_date.__eq__(as_datetime.replace(day= - different_day))) Second, the patch introduces dependence of the baseclass method (date_richcompare) on a particular subclass (PyDateTime_Check). This is against OOP principles. I am not sure how the "equality not symmetric" issue can be fixed. In my opinion current datetime implementation is fighting OOP and violating the substitution principle in an attempt to prevent date to datetime comparison. I would prefer seeing one of two things: either datetime not inheriting from date or making datetime to date comparison compare date part alone. Once you stop fighting OOP principles, symmetry of equality for subclasses will follow from that for the base class automatically. Given that either of these solutions means a major change, I think it is best to leave the things as they are now. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5516> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
