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
bpo-34552: Clarify built-in types comparisons #9035
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please check the build failures and try to fix them
fb64376
to
42a27a9
Compare
@auvipy I fixed the failures. I think we should add skip news label in this pr |
Doc/library/stdtypes.rst
Outdated
comparing a complex number with another built-in numeric type, when the objects | ||
are of different types that cannot be compared, or in other cases where there is | ||
no defined ordering. | ||
Objects of different types, except different numeric types, should never compare equal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you add "should"? This is a descriptive section (explaining how builtin objects work) not a prescription for how one should implement objects in general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you are right.
Doc/library/stdtypes.rst
Outdated
are of different types that cannot be compared, or in other cases where there is | ||
no defined ordering. | ||
Objects of different types, except different numeric types, should never compare equal. | ||
The ``==`` defaults to :keyword:`is` if both object's :meth:`__eq__` method returns NotImplemented. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
The
==
operator is always defined but for some object types is equivalent to :keyword:is
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about
The
==
operator is always defined but for some object types (for example, function objects) is equivalent to :keyword:is
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd use class objects
instead of function objects
-- the intro to this section (L15) mentions those explicitly.
FWIW reading that section makes me think we should replace compared
on L23 with compared for equality
.
Doc/library/stdtypes.rst
Outdated
The ``<=``, ``>`` and ``>=`` operators aren't always defined, they will raise a | ||
:exc:`TypeError` exception when comparing a complex number with another built-in | ||
numeric type, when the objects are of different types that cannot be compared, | ||
or in other cases where there is no defined ordering. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
The
<=
,>
and>=
operators are only defined where they make sense; for example, they raise a
:exc:TypeError
exception when one of the arguments is a complex number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we talk about !=
operator here? I'm not sure is !=
always defined just like ==
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In new enough 3.x versions, if you define __eq__
but leave __ne__
undefined, !=
falls back to not ==
. I don't think it's worth mentioning, since this is not the language reference, just a brief summary of typical behavior of common objects.
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
42a27a9
to
17bd781
Compare
17bd781
to
4a12731
Compare
Can you add a news blurb? That will clear the bedevere/news test failure. Also please don't amend your local commit and |
Thank you for point it out. |
@Windsooon DO you have time to push a new version reflecting the latest discussion? |
@gvanrossum I do have time, I added the blurb, but I'm not sure what should I do next? |
Ah, sorry. I'm not sure what happened -- maybe you amended your commit, maybe I didn't re-check the latest version. I am now happy and will let the bot do the rest. |
Some updates to ancient text about comparisons; fixes bp-34552.