You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
collections.abc defines Hashable which should correspond to hashable objects. However, this is a little tricky, since hashability is not an always inherited property. Consider object vs. list:
There is currently no way defined in the PEP for representing the fact that list is not hashable. We could have object be a subclass of Hashable, but without some further rules this would make list hashable as well.
Here is one potential way of specifying this in code or stubs:
class list(...)
...
def __hash__(self):
raise NotImplementedError() # A type checker should recognize this
We could still not always check hashability reliably. For example, a variable with type object should probably be considered hashable, but it could actually be a list, which is not hashable. This is probably a very minor problem, though. Having a way of rejecting Dict[List[int], int] would be nice. We'd also need something like bounded polymorphism, though, so that we could they that a dictionary key type must a subtype of Hashtable.
Another alternative would be to not make object hashable, but since hash(object()) is okay, it doesn't sound right.
The text was updated successfully, but these errors were encountered:
In real code the convention (explicitly checked for by the hash() builtin) is that if you set hash to None that means the class is not hashable. Literally:
an abstract base class, UnHashable, which describes unhashable objects perhaps?
We could always create abc's for describing anything we wanted, and make them support the [] operator for getting an object to use in the typing system... or at least I'd hope we can extend the already suggested classes.
collections.abc
definesHashable
which should correspond to hashable objects. However, this is a little tricky, since hashability is not an always inherited property. Considerobject
vs.list
:There is currently no way defined in the PEP for representing the fact that
list
is not hashable. We could haveobject
be a subclass ofHashable
, but without some further rules this would makelist
hashable as well.Here is one potential way of specifying this in code or stubs:
We could still not always check hashability reliably. For example, a variable with type
object
should probably be considered hashable, but it could actually be alist
, which is not hashable. This is probably a very minor problem, though. Having a way of rejectingDict[List[int], int]
would be nice. We'd also need something like bounded polymorphism, though, so that we could they that a dictionary key type must a subtype ofHashtable
.Another alternative would be to not make
object
hashable, but sincehash(object())
is okay, it doesn't sound right.The text was updated successfully, but these errors were encountered: