Special-casing __hash__ #2284

Activity

1. srittau

   added

   topic: typing specFor improving the typing specFor improving the typing spec

   on May 12, 2026
2. JelleZijlstra commented on May 12, 2026

   

   JelleZijlstra

   on May 12, 2026

   Member

   More actions

   There was a previous discussion about this at https://discuss.python.org/t/hash-eq-and-lsp/68138 .

   Your proposal seems to be basically the status quo, where Hashable is a protocol defining the __hash__ method. A problem with that status quo is that object is hashable, so a subclass that is not hashable is (correctly!) marked by type checkers as having an invalid override. You propose to allow that unsafe override. Mike's proposal in the linked thread was instead to say that object has __hash__ of type None | () -> int, with a special case to allow instances of exactly object to be hashable.
3. srittau commented on May 12, 2026

   

   srittau

   on May 12, 2026

   CollaboratorAuthor

   More actions

   Considering that the status quo is the status quo (and mirrors the implementation, i.e. classes are hashable by default), documenting this would be a big step forward.
4. randolf-scholz commented on May 12, 2026

   

   randolf-scholz

   on May 12, 2026

   Last edited by randolf-scholz

   Contributor

   More actions

   Sub-classes inherit their parent's hashability, unless overridden.

   This doesn't match runtime, as cpython removes __hash__ if a subclass implements __eq__, but not __hash__:

   >>> class Foo: ...
   ... 
   >>> hash(Foo())
   8496821607350
   >>> class Bar(Foo):
   ...     def __eq__(self, other): return False
   ...     
   >>> hash(Bar())
   Traceback (most recent call last):
     File "<python-input-3>", line 1, in <module>
       hash(Bar())
       ~~~~^^^^^^^
   TypeError: unhashable type: 'Bar'

   This is exactly what makes static typing for __hash__ so tricky..

   👍React with 👍1Reacted by Dave Halter
5. srittau commented on May 13, 2026

   

   srittau

   on May 13, 2026

   Last edited by srittau

   CollaboratorAuthor

   More actions

   This doesn't match runtime, as cpython removes __hash__ if a subclass implements __eq__, but not __hash__:

   This is then something that type checkers also need to replicate and should be added to the list above, according to the philosophy "special casing in the Python interpreter means special casing in type checkers".