You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Over at typeshed, the stub for max()has just been changed. max() is now annotated as requiring arguments to have a __gt__ method rather than a __lt__ method, as this more accurately reflects the C code for max(). However, the only effect of this change is to "flip" the errors that mypy reports: it will now error out on the class that only has a __lt__ method, instead of the class that only has a __gt__ method.
One potential solution to this problem could be to further revise the typeshed stub. However, I have been advised by @srittau that this would be a suboptimal solution, as __gt__/__lt__ probably need to be special-cased by mypy and other type-checkers to some extent.
Your Environment
Mypy version used: 0.910
Mypy command-line flags: --strict, --show-error-codes (the same errors occur without the --strict flag)
Mypy configuration options from mypy.ini (and other config files): None
Python version used: 3.10
The text was updated successfully, but these errors were encountered:
Bug Report
Mypy raises false-positive errors if you pass an object that only has a
__gt__
method tomax()
.To Reproduce
Consider the following class definitions:
Here's how they behave with max() at runtime in Python 3.10:
Expected Behavior
Mypy should raise no errors for code such as this, as it works fine at runtime and is perfectly type-safe.
Actual Behavior
Mypy raises errors for the following snippet of code, a typed equivalent to the untyped code above:
Over at typeshed, the stub for
max()
has just been changed.max()
is now annotated as requiring arguments to have a__gt__
method rather than a__lt__
method, as this more accurately reflects the C code formax()
. However, the only effect of this change is to "flip" the errors that mypy reports: it will now error out on the class that only has a__lt__
method, instead of the class that only has a__gt__
method.One potential solution to this problem could be to further revise the typeshed stub. However, I have been advised by @srittau that this would be a suboptimal solution, as
__gt__
/__lt__
probably need to be special-cased by mypy and other type-checkers to some extent.Your Environment
--strict
,--show-error-codes
(the same errors occur without the--strict
flag)mypy.ini
(and other config files): NoneThe text was updated successfully, but these errors were encountered: