Author jess.austin
Recipients Alexander.Belopolsky, jackdied, jess.austin, mark.dickinson, ncoghlan
Date 2010-04-21.18:33:49
SpamBayes Score 2.96617e-07
Marked as misclassified No
Message-id <1271874830.95.0.64288973065.issue5516@psf.upfronthosting.co.za>
In-reply-to
Content
To be systematic, without the patch:

>>> D(1900, 1, 1) > DT(1900, 1, 1)
False
>>> D(1900, 1, 1) < DT(1900, 1, 1)
False
>>> DT(1900, 1, 1) > D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D
>>> DT(1900, 1, 1) < D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D


with the patch:

>>> D(1900, 1, 1) > DT(1900, 1, 1)
True
>>> D(1900, 1, 1) < DT(1900, 1, 1)
False
>>> DT(1900, 1, 1) > D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D
>>> DT(1900, 1, 1) < D(1900, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare DT to D


It might seem like the latter behavior is marginally better, but really this is just a mess, since a date-datetime comparison TypeErrors in all directions.  I appreciate Alexander's more experienced perspective, but it's not obvious to me that this problem is insoluble simply due to OOP algebra.  I'm going to keep tinkering with this to see if there isn't a way to satisfy his concerns AND fix these bugs WITHOUT breaking the established (and admittedly anti-OOP) behavior that dates are not equal to datetimes.

(Incidentally, the test I removed still seems to be an arbitrary ad-hoc requirement that subclasses of date behave differently than date itself.  I don't see how one could rely on this given the other inconsistencies with date subclasses, and so violating this in order to fix more serious problems seems acceptable.)

I'm reminded of the set and frozenset situation, which seems almost dual to this one.  set and frozenset don't inherit from each other, but they do compare.  This seems to bite you only when you try to redefine comparison in subclasses.
History
Date User Action Args
2010-04-21 18:33:51jess.austinsetrecipients: + jess.austin, mark.dickinson, ncoghlan, jackdied, Alexander.Belopolsky
2010-04-21 18:33:50jess.austinsetmessageid: <1271874830.95.0.64288973065.issue5516@psf.upfronthosting.co.za>
2010-04-21 18:33:49jess.austinlinkissue5516 messages
2010-04-21 18:33:49jess.austincreate