New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
datetime's comparison methods do not return NotImplemented when they should #52253
Comments
datetime's comparison methods do not return NotImplemented when they should. As a result, if you implement a class that can compare itself with a datetime object, this only works if your class on on the left side of the comparison operation. This is true for equality as well as ordering operations. |
Confirmed on trunk, works as expected in py3k. |
Work-in-progress test for this issue. I'll clean up the test and start work on a patch later tonight. |
Thomas, could you write a unit test to go along with your patch? |
See bpo-5516 for a related issue. |
Is there a patch with a fix or just a patch with a test. If the later, maybe someone can remove a patch keyword. |
It's just a test. Finishing the patch completely slipped my mind. I'll work on it later tonight. |
You're right. I asked Thomas the wrong question, and the Keywords and Stage need updating. Thomas, do you still plan to submit a patch that fixes the problem? |
I'm still reasonably new to the codebase, but I'm certainly going to try to fix the issue. |
Great! If you get stuck or have a question, just ask. :-) |
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:
Now >>> date(1,1,1) == A()
True This is a documented feature: """ 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 bpo-5516. |
Thanks for pointing that out. For what it's worth, if I understand the documentation correctly the goal is to prevent the following misleading comparisons: date with time It's unfortunate that it throws a TypeError for all comparisons (unlike complex numbers which only throw a TypeError when comparing with numbers), but I suppose you are right that it's too late to fix this in 2.x. |
Any objections to closing this as "won't fix"? |
None here. |
Closing now. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: