Skip to content

Return bool from operator comparison functions - #6449

Closed
AlexWaygood wants to merge 1 commit into
python:masterfrom
AlexWaygood:patch-1
Closed

AlexWaygood wants to merge 1 commit into
python:masterfrom
AlexWaygood:patch-1

Conversation

@AlexWaygood

Copy link
Copy Markdown
Member

No description provided.

@github-actions

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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

AlexWaygood commented Nov 30, 2021 •

Copy link
Copy Markdown
Member Author

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
Copy Markdown
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
Copy Markdown
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

Akuli commented Nov 30, 2021

Copy link
Copy Markdown
Collaborator

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
Copy Markdown
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

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants