MyPy does not enforce Hashability #2455

Activity

1. gvanrossum commented on Nov 15, 2016

   

   gvanrossum

   on Nov 15, 2016

   Member

   More actions

   Other than python/typing#11, not that I know.
2. JukkaL

   added

   feature

   priority-2-low

   on Jan 16, 2017
3. ilevkivskyi commented on Dec 18, 2019

   

   ilevkivskyi

   on Dec 18, 2019

   Member

   More actions

   Another example appeared in #8150. Also I think it makes to raise priority to normal as this is relatively common cause of confusion.

   👍React with 👍1Reacted by Finite State Machine
4. ilevkivskyi

   added

   priority-1-normal

   and removed

   priority-2-low

   on Dec 18, 2019
5. erictraut commented on Aug 10, 2023

   

   erictraut

   on Aug 10, 2023

   More actions

   Pyright recently added support for this feature. It wouldn't have been possible without some significant modifications to typeshed stubs. See this, this, and this for details. Now that these changes are in typeshed, it should be relatively easy to add this check to mypy.

   🎉React with 🎉3Reacted by Ilya Priven, Finite State Machine and JR Heard
6. finite-state-machine commented on Oct 30, 2023

   

   finite-state-machine

   on Oct 30, 2023

   Last edited by finite-state-machine

   More actions

   In case it's useful to have gists/tests for this:

   With regular objects:

   from __future__ import annotations
   from typing import *
   from typing_extensions import (
           reveal_type,
           )
   
   class SomeClass:
   
       def __eq__(self, other: object) -> bool:
           # defining '__eq__()' without defining '__hash__()' implicitly
           # makes instances of this class unhashable, and sets '__hash__'
           # to 'None'
           return super().__eq__(other)
   
   instance = SomeClass()
   
   hash(instance)
           # mypy actual behavior:    no error issued
           # mypy expected behavior:  issue an error, since this fails at runtime
           # runtime behavior:        TypeError: unhashable type: 'SomeClass'
   
   reveal_type(type(instance).__hash__)
           # mypy actual behavior:    Revealed type is "def (self: builtins.object) -> builtins.int"
           # mypy expected behavior:  Revealed type is "None"
           # at runtime:              Runtime type is 'NoneType'

   I had been under the impression that types were always hashable, but it seems that's not always the case if a metaclass is in play – there's nothing different or special about this case:

   from __future__ import annotations
   from typing import *
   from typing_extensions import (
           reveal_type,
           )
   
   class SomeMeta(type):
   
       def __eq__(self, other: object) -> bool:
           # defining '__eq__()' without defining '__hash__()' implicitly
           # makes instances of this metaclass unhashable, and sets
           # '__hash__' to 'None'
           return super().__eq__(other)
   
   
   class SomeClass(metaclass=SomeMeta):
   
       pass
   
   
   hash(SomeClass)
           # mypy actual behavior:    no error issued
           # mypy expected behavior:  issue an error, since this fails at runtime
           # runtime behavior:        TypeError: unhashable type: 'SomeMeta'
   
   
   reveal_type(type(SomeClass).__hash__)
           # mypy actual behavior:    Revealed type is "def (self: object) -> int"
           # mypy expected behavior:  Revealed type is "None"
           # at runtime:              Runtime type is 'NoneType'