BUG: EAs should not be hashable
This turns out to be a blocker for some cleanup in index.pyx
LGTM - do we need a `whatsnew` ? Do we actually want to commit to this? Just wonder if this would conflict with some of the work I think @TomAugspurger did before to try and create a non-mutable dataframe yes mutable things are not hashable
we do allow hash_pandas_object to work though This change seems fine. Can you say more about the motivation though? As I can imagine an immutable array that is hasable, so we mange shouldn’t rely on unhashabilty.  > Can you say more about the motivation though? As I can imagine an immutable array that is hasable, so we mange shouldn’t rely on unhashabilty.

I'm working on indexing code and want to simplify a check

```
cdef inline bint is_definitely_invalid_key(object val):
    if isinstance(val, tuple):
        try:
            hash(val)
        except TypeError:
            return True

    # we have a _data, means we are a NDFrame
    return (isinstance(val, slice) or util.is_array(val)
            or isinstance(val, list) or hasattr(val, '_data'))

    cpdef get_loc(self, object val):
        cdef:
            Py_ssize_t loc

        if is_definitely_invalid_key(val):
            raise TypeError(f"'{val}' is an invalid key")
    [...]
```

to just check for hashability.  Doing that breaks a couple of tests because EAs are currently hashable > to just check for hashability. Doing that breaks a couple of tests because EAs are currently hashable

When an immutable, 3rd-party EA comes along that's hashable, will that break again? > When an immutable, 3rd-party EA comes along that's hashable, will that break again?

If that EA gets passed as a `key` to `index._engine.(get_loc|get_value|contains)` then it may give `(KeyError|KeyError|False)` instead of raising a `TypeError` thanks @jbrockmendel 