Detect unhashable elements in a set?

[AlexWaygood]

In a typeshed PR the other day, a contributor tried to annotate an object with frozenset[list[str]]. It's obviously impossible to have a frozenset of lists, as lists aren't hashable, and so I was surprised that none of the CI checks raised an error.

I'm in two minds about whether adding a check for that here would be a good idea:

• It would be very difficult for us to reliably detect whether an object is hashable or not
• Ideally this is something that would be flagged by a type-checker, not a linter
• BUT it might be difficult for even a type-checker to detect whether or not an object is hashable.
• AND we could probably fairly easily hardcode a list of common mutable objects that can't be used in sets, frozensets or dict keys. It wouldn't be comprehensive, but it would detect the most common errors.

What do we think? Worth doing?

[srittau]

I'm -0 on this for the reasons you listed. :) No active opposition from me, but I'd prefer to see type checkers improved (somehow) to handle this case.

[Akuli]

It's obviously impossible to have a frozenset of lists, as lists aren't hashable

This isn't correct. Consider functools._HashedSeq, which is a subclass of list that has __hash__. It's unsafe, but good enough for internal use within functools. That said, I can't think of any situation where this would be a problem in practice.

[AlexWaygood]

It's obviously impossible to have a frozenset of lists, as lists aren't hashable

This isn't correct. Consider functools._HashedSeq, which is a subclass of list that has __hash__. It's unsafe, but good enough for internal use within functools. That said, I can't think of any situation where this would be a problem in practice.

Sure, but if you had a frozenset with elements of functools._HashedSeq, you'd annotate that with frozenset[_HashedSeq[foo]], not frozenset[list[foo]]. And this is basically why it's really difficult for this kind of thing to be implemented comprehensively by a type-checker, no? You can't assume that a subclass of a hashable type will be hashable, and you can't assume that a subclass of an unhashable type will be unhashable.

[JelleZijlstra]

I feel like this is a thing for typecheckers to fix, not us.

[AlexWaygood]

Alrighty. Thanks for the discussion!