This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, jackdied, jess.austin, ncoghlan
Date 2010-04-21.16:51:26
SpamBayes Score 0.00174406
Marked as misclassified No
Message-id <>
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 = ( + 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.
Date User Action Args
2010-04-21 16:51:29Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, ncoghlan, jackdied, jess.austin
2010-04-21 16:51:29Alexander.Belopolskysetmessageid: <>
2010-04-21 16:51:27Alexander.Belopolskylinkissue5516 messages
2010-04-21 16:51:27Alexander.Belopolskycreate