__lt__ and __gt__ should always be allowed to have return type bool

[gvanrossum]

When the argument to __lt__ or __gt__ (or probably others) has type Any, mypy insists that the return type is also Any. (This is hardcoded: https://github.com/JukkaL/mypy/blob/master/mypy/checker.py#L621-L622 )

Why is this? Is it related to #363?

It's inconvenient.

[gvanrossum]

Example:

from typing import Any

class Infinity:
    def __lt__(self, other: Any) -> bool:  # E: error: "Any" return type expected since argument to __lt__ has type "Any"
        return False
    def __gt__(self, other: Any) -> bool:  # E: error: "Any" return type expected since argument to __lt__ has type "Any"
        return True

[JukkaL]

This guards against a weird corner case that could cause a wrong type to be inferred. The example in the comment near the linked code gives some context (though it's not a complete example). It originates from my PhD research where type soundness was a major thing. As the goals of mypy have shifted, this check doesn't make sense any more. I'll just remove it.

[kamahen]

It seems that mypy doesn't allow __ne__ returning NotImplemented, (this is allowed for __eq__).
And when I try explicitly adding NotImplemented as a possible return type, I get a run-time error:

  File ".../pod.py", line 65, in PlainOldData
    def __ne__(self, other: Any) -> Union[bool, NotImplemented]:
  File "/usr/lib/python3.6/typing.py", line 682, in inner
    return func(*args, **kwds)
  File "/usr/lib/python3.6/typing.py", line 800, in __getitem__
    parameters = tuple(_type_check(p, msg) for p in parameters)
  File "/usr/lib/python3.6/typing.py", line 800, in <genexpr>
    parameters = tuple(_type_check(p, msg) for p in parameters)
  File "/usr/lib/python3.6/typing.py", line 374, in _type_check
    raise TypeError(msg + " Got %.100r." % (arg,))
TypeError: Union[arg, ...]: each arg must be a type. Got NotImplemented.

If I change this to def __ne__(self, other: Any) -> Union[bool, type(NotImplemented)]:, then mypy complains:

error: invalid type comment or annotation
note: Suggestion: use type[...] instead of type(...)

and when I try following the suggestion, I get a runtime error:

TypeError: 'type' object is not subscriptable

[gvanrossum]

Please use a new issue for such feedback. The root cause seems to be that __ne__ is not included in the list BINARY_MAGIC_METHODS in mypy/sharedparse.py. You could submit a PR that fixes this (and adds a test).