[issue37685] Fix equality checks for some types

Serhiy Storchaka added the comment: Thank you Łukasz. I considered this as a bug fix, but was not sure that we should fix these bugs. They were here from the beginning. Josh, as for using total_ordering, I think it is a different issue. I did not want to change the behavior except fixing

[issue37685] Fix equality checks for some types

Łukasz Langa added the comment: Unfortunately, we released 3.8.0, 3.8.1, and 3.8.2rc1 without this change. It seems too late in the release cycle to introduce this change. I'd feel better seeing it in 3.9 only. Sorry that we didn't act in time to include this in 3.8.0. --

[issue37685] Fix equality checks for some types

Change by Serhiy Storchaka : -- pull_requests: +17263 pull_request: https://github.com/python/cpython/pull/17836 ___ Python tracker ___

[issue37685] Fix equality checks for some types

Serhiy Storchaka added the comment: Łukasz, are you fine with backporting PR 14952 to 3.8? -- nosy: +lukasz.langa ___ Python tracker ___

[issue37685] Fix equality checks for some types

Serhiy Storchaka added the comment: New changeset 7d44e7a4563072d0fad00427b76b94cad61c38ae by Serhiy Storchaka in branch 'master': bpo-37685: Use singletons ALWAYS_EQ and NEVER_EQ in more tests. (GH-15167) https://github.com/python/cpython/commit/7d44e7a4563072d0fad00427b76b94cad61c38ae

[issue37685] Fix equality checks for some types

Serhiy Storchaka added the comment: New changeset 662db125cddbca1db68116c547c290eb3943d98e by Serhiy Storchaka in branch 'master': bpo-37685: Fixed __eq__, __lt__ etc implementations in some classes. (GH-14952) https://github.com/python/cpython/commit/662db125cddbca1db68116c547c290eb3943d98e

[issue37685] Fix equality checks for some types

Change by Serhiy Storchaka : -- pull_requests: +14899 pull_request: https://github.com/python/cpython/pull/15167 ___ Python tracker ___

[issue37685] Fix equality checks for some types

Serhiy Storchaka added the comment: New changeset 6ed20e54e4c110e9adcfb70aba85310625e3edb4 by Serhiy Storchaka in branch '3.7': [3.7] bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996) (GH-15104)

[issue37685] Fix equality checks for some types

Change by Serhiy Storchaka : -- pull_requests: +14846 pull_request: https://github.com/python/cpython/pull/15104 ___ Python tracker ___

[issue37685] Fix equality checks for some types

miss-islington added the comment: New changeset dde944f9df8dea28c07935ebd6de06db7e575c12 by Miss Islington (bot) in branch '3.8': bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996)

[issue37685] Fix equality checks for some types

Change by miss-islington : -- pull_requests: +14844 pull_request: https://github.com/python/cpython/pull/15102 ___ Python tracker ___

[issue37685] Fix equality checks for some types

Serhiy Storchaka added the comment: New changeset 17e52649c0e7e9389f1cc2444a53f059e24e6bca by Serhiy Storchaka in branch 'master': bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996)

[issue37685] Fix equality checks for some types

Change by Serhiy Storchaka : -- pull_requests: +14762 pull_request: https://github.com/python/cpython/pull/14996 ___ Python tracker ___

[issue37685] Fix equality checks for some types

Kyle Stanley added the comment: > Serhiy: Is there a reason not to use the functools.total_ordering decorator > on TimerHandle, so you can get rid of __le__/__ge__/__gt__ rather than fixing > them > individually? I strongly agree with this suggestion, unless there's some unique behavior

[issue37685] Fix equality checks for some types

Vedran Čačić added the comment: Thanks for the clarification. Yes, now I see how it really works, but I saw some comment about not wanting to backport it to 3.7, because it changes the semantics. Now that I understand the implementation, it seems to me that it really doesn't change the

[issue37685] Fix equality checks for some types

Josh Rosenberg added the comment: Serhiy: Is there a reason not to use the functools.total_ordering decorator on TimerHandle, so you can get rid of __le__/__ge__/__gt__ rather than fixing them individually? I notice at least one behavioral difference (total_ordering's le/ge methods use

[issue37685] Fix equality checks for some types

Josh Rosenberg added the comment: @p-ganssle: Yup. If both sides return NotImplemented, __eq__ and __ne__ return a result based on an identity comparison; all other rich comparisons raise TypeError in that case. Code is here: https://github.com/python/cpython/blob/3.7/Objects/object.c#L679

[issue37685] Fix equality checks for some types

Paul Ganssle added the comment: @veky I can't be sure, but I think you may not understand what returning `NotImplemented` does - this makes comparisons *more* versatile, not less. The way it works is that when Python does, for example, x == y, it will first call x.__eq__(y) and check the

[issue37685] Fix equality checks for some types

Vedran Čačić added the comment: Wat?? Are we heading towards the world where 3.2 == 'something' is NotImplemented? I understand `__lt__`, of course, but in my opinion Python has always defined equality comparisons between different types. I think this is a huge regression. -- nosy:

[issue37685] Fix equality checks for some types

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +14721 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14952 ___ Python tracker

[issue37685] Fix equality checks for some types

New submission from Serhiy Storchaka : The __eq__ implementation should return NotImplemented instead of False or raising an exception (like AttributeError or TypeError) when it does not support comparison with the other operand's type. It is so for most of implementations in the stdlib, but