Attempt to narrow tuple.__hash__ to flag unhashable entries in the tuple

[jonathandung]

Closes #15851.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[jonathandung]

That was somewhat surprising.

[srittau]

Could you add some tests to stdlib/@tests/test_cases/builtins/check_tuple.py? Especially what happens if the element are hashable/not hashable, and testing with zero-length, variable length, and fixed length tuples. See the other tests in stdlib/@tests/test_cases for examples on how to write tests.

Important: The tests are never run, only type checked, so they don't need to be runnable, and should skip unnecessary setup etc.

[JelleZijlstra]

Both tuples and hashing are special-cased by type checkers so it's not entirely surprising that this appears to do nothing to mypy. Worth checking what we do to other type checkers, though.

[AlexWaygood]

I'll do an experimental PR to ty to see what it does to us. Hashable causes lots of trouble for ty in general due to the LSP violations everywhere regarding Hashable so it's possible it might be more problematic for us (but let's see)

Edit: testing this in astral-sh/ruff#25526

[AlexWaygood]

The experiment gave a clean ecosystem report for ty (again, somewhat surprising 😄): astral-sh/ruff#25526 (comment). There are a few failing tests on that PR but they're nothing to worry about -- just snapshots that would need to be updated.

[JelleZijlstra]

If it doesn't do anything then that also means there's little reason to make this change, though.

[jonathandung]

I think after merging #15754 (if ever), some errors are sure to emerge