Feature request: warn on set creation with unhashable types

[gtkacz]

Summary

If an user is trying to create a set or similar on unhashable types, it will error with something like TypeError: unhashable type: 'list'. This can easily be warned by ruff if it knows the type of the variable by checking for the existence of the __hash__ method.

Which would warn the user in something like:

some_set = set([{'foo': 'bar'}])

Worth pointing out that iterables with root-level hashable types can be passed, e.g.:

set({'foo': 'bar'})
>>> {'foo'}

set([0, 1, 2])
>>> {0, 1, 2}

Example checker implementation in Python:

def is_unhashable(var: Any) -> bool:
	if not var.__class__.__hash__ and (var.__class__.__iter__ and not var[0].__class__.__hash__):
		return True

	return False

is_unhashable([0, 1, 2])
>>> False

is_unhashable([{'foo': 'bar'}])
>>> True

is_unhashable('foo')
>>> False

[ntBre]

My first thought was that this might be a better fit for a type checker, but it doesn't look like ty, pyright, or mypy flag this example either.

[MichaReiser]

Yeah, that was my thought too but set takes an Iterable[T] without any constraints on T. There's an Hashable Protocol but it isn't widely used. @AlexWaygood probably knows more.

We could hard code common cases but a proper implementation requires multifile analysis, which Ruff doesn't support yet.

[dylwil3]

A relevant typeshed issue: python/typeshed#9571

[AlexWaygood]

Type checkers are mostly useless for accurately inferring hashability, unfortunately. There is a Hashable protocol, but a major problem is that object is inferred as a subtype of Hashable (because hash(object()) works at runtime). You can logically infer from this that all Python objects are hashable, since all Python types are subtypes of object... but wait, that's obviously not true.

Hashability in Python just doesn't follow the normal rules that Python type checkers are meant to assume when they type-check Python code; it's a fundamental violation of the Liskov Substitution Principle baked deep into the language. I actually think Ruff may be able to do better than ty here just by hardcoding a few common cases of things that are known not to be hashable; it's very hard for type checkers to get this right.

[AlexWaygood]

For related discussion, see:

• typing.Hashable | typing.Sequence[typing.Hashable] not matching ["x"] in ty==0.0.1a20 ty#1132
• [ty] Treat Hashable, and similar protocols, equivalently to object for subtyping/assignability #20284
• Check for redundant object unions PyCQA/flake8-pyi#283 (comment)

• ruff/crates/ty_vendored/vendor/typeshed/stdlib/typing.pyi

  Lines 867 to 873 in 1d18847

  	@runtime_checkable
  	class Hashable(Protocol, metaclass=ABCMeta):
  	# TODO: This is special, in that a subclass of a hashable class may not be hashable
  	# (for example, list vs. object). It's not obvious how to represent this. This class
  	# is currently mostly useless for static checking.
  	@abstractmethod
  	def __hash__(self) -> int: ...