This is more of a typeshed issue. Currently max() is stubbed as accepting basically anything (https://github.com/python/typeshed/blob/master/stdlib/2and3/builtins.pyi#L1318). Perhaps it could be changed to accept only types that define <.

Hello, today I sketched a solution for this. I wrote my own clone of max() in Python to be able to test it and run Mypy experiments. This is what I got: do you think I am on the right track? What am I missing? (I'll rename the protocol and type vars with leading _ before I merge into builtins.pyi for a PR)

https://gist.github.com/ramalho/1ed164b65ec8c36716ca9c90780890b8

@ramalho That looks about right! A couple of the overloads (1 and 2 for example) can be merged by putting key: None = ....

Thanks, @JelleZijlstra!

You are right, I was able to merge 3 overloads, now down to 6: https://gist.github.com/ramalho/1ed164b65ec8c36716ca9c90780890b8

It occurred to me that the Comparable protocol can also be used for sorted(), and that would be a smaller PR.

So my plan is to send a PR for the sorted type hints, which will include defining Comparable and a TypeVar bounded by it. After that PR is merged, I'll do a second one for max and min.

Would you prefer that I file a bug about sorted first, or may I just send the PR?

Thanks! No need to file an issue.

I feel like there's some chance narrowing the types of sorted() and max() will lead to false positives, just because of how common these are (maybe some types that should define __lt__ are missing it in stubs?). Once you submit a PR, I'll test it on our codebase to see if anything like that comes up.

I am working on this. Instead of Comparable I think SupportsLessThan is a better name: precise, explicit, and follows the naming convention of several SupportsXyz protocols already defined in typing.

class _SupportsLestThan(Protocol):
    def __lt__(self, other: Any) -> bool: ...

First PR will touch str.list() and listed().

Fantastic, thanks. I'll never make that silly error again. 👍