Skip to content

bpo-34552: Clarify built-in types comparisons#9035

Merged
miss-islington merged 2 commits into
python:masterfrom
Windsooon:bpo-34552
Sep 14, 2018
Merged

bpo-34552: Clarify built-in types comparisons#9035
miss-islington merged 2 commits into
python:masterfrom
Windsooon:bpo-34552

Conversation

@Windsooon

@Windsooon Windsooon commented Sep 2, 2018

Copy link
Copy Markdown
Contributor

Some updates to ancient text about comparisons; fixes bp-34552.

@Windsooon

Copy link
Copy Markdown
Contributor Author

@gvanrossum

@auvipy auvipy left a comment

Copy link
Copy Markdown

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

@Windsooon

Copy link
Copy Markdown
Contributor Author

@auvipy I fixed the failures. I think we should add skip news label in this pr

Comment thread Doc/library/stdtypes.rst Outdated

Copy link
Copy Markdown
Member

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right.

Comment thread Doc/library/stdtypes.rst Outdated

Copy link
Copy Markdown
Member

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.

@Windsooon Windsooon Sep 11, 2018

Copy link
Copy Markdown
Contributor Author

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.

Copy link
Copy Markdown
Member

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.

Comment thread Doc/library/stdtypes.rst Outdated

Copy link
Copy Markdown
Member

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.

Copy link
Copy Markdown
Contributor Author

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 ==.

Copy link
Copy Markdown
Member

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.

@bedevere-bot

Copy link
Copy Markdown

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 I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@gvanrossum

Copy link
Copy Markdown
Member

Can you add a news blurb? That will clear the bedevere/news test failure.

Also please don't amend your local commit and git push -f -- instead, create a new local commit and git push. This is easier for the reviewers. Your stack of local commits will be squashed when we merge the diff.

@Windsooon

Copy link
Copy Markdown
Contributor Author

Can you add a news blurb? That will clear the bedevere/news test failure.

Also please don't amend your local commit and git push -f -- instead, create a new local commit and git push. This is easier for the reviewers. Your stack of local commits will be squashed when we merge the diff.

Thank you for point it out.

@gvanrossum

Copy link
Copy Markdown
Member

@Windsooon DO you have time to push a new version reflecting the latest discussion?

@Windsooon

Copy link
Copy Markdown
Contributor Author

@gvanrossum I do have time, I added the blurb, but I'm not sure what should I do next?

@gvanrossum

Copy link
Copy Markdown
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation in the Doc dir

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants