8000 Return `bool` from `operator` comparison functions by AlexWaygood · Pull Request #6449 · python/typeshed · GitHub
[go: up one dir, main page]
Skip to content

Return bool from operator comparison functions #6449

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Return bool from operator comparison functions #6449

wants to merge 1 commit into from

Conversation

AlexWaygood
Copy link
Member

No description provided.

@github-actions
Copy link
Contributor

Diff from mypy_primer, showing the effect of this PR on open source code:

pandas (https://github.com/pandas-dev/pandas)
+ pandas/io/formats/style.py:3511: error: Unsupported left operand type for & ("object")  [operator]

@JelleZijlstra
Copy link
Member

Returning a non-bool from these methods isn't all that uncommon; numpy arrays do it. Perhaps we could do something fancy here with generic Protocols.

(Also, unrelatedly, thanks for all the enthusiasm in improving things! I really appreciate your work here.)

@AlexWaygood
Copy link
Member Author

(Also, unrelatedly, thanks for all the enthusiasm in improving things! I really appreciate your work here.)

Thanks 🙂 also, do let me know if I'm being a pain at any point!

@AlexWaygood
Copy link
Member Author
AlexWaygood commented Nov 30, 2021 •
edited
Loading

Perhaps we could do something fancy here with generic Protocols.

Hmmmm. Do you have anything in mind? I actually wasn't aware of the numpy situation with these methods 😕

@AlexWaygood AlexWaygood marked this pull request as draft November 30, 2021 09:27
@AlexWaygood AlexWaygood deleted the patch-1 branch November 30, 2021 19:02
@JelleZijlstra
Copy link
Member

Hmmmm. Do you have anything in mind?

Sorry I missed this. If we had only one operand, it would be something like a protocol with __eq__() -> _T, then operator.eq takes the Protocol and returns _T. But in fact we have to look at both operands, so we need something more complicated.

@AlexWaygood
Copy link
Member Author

But in fact we have to look at both operands, so we need something more complicated.

Yeah. I tried doing something more ✨fancy✨ in #6448, but a lot of the false-positives seemed to arise from giving e.g. __lt__ and __gt__ different signatures. So that's quite a big constraining factor here 😕

@Akuli
Copy link
Collaborator
Akuli commented Nov 30, 2021

I think we should also distinguish between x < y and x.__lt__(y). An operator like < will call y.__gt__(x), if y.__gt__ exists but x.__lt__ doesn't. This was previously discussed when improving the type hint for max().

@AlexWaygood
Copy link
Member Author

I think we should also distinguish between x < y and x.__lt__(y). An operator like < will call y.__gt__(x), if y.__gt__ exists but x.__lt__ doesn't. This was previously discussed when improving the type hint for max().

Just WAIT till you see my next PR

@AlexWaygood AlexWaygood mentioned this pull request Nov 30, 2021
Merged
@AlexWaygood AlexWaygood mentioned this pull request Jan 31, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@AlexWaygood @JelleZijlstra @Akuli
0