-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
BUG: EAs should not be hashable #30908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
LGTM - do we need a |
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 |
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. |
I'm working on indexing code and want to simplify a check
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? |
If that EA gets passed as a |
@@ -1073,6 +1073,9 @@ def _reduce(self, name, skipna=True, **kwargs): | |||
""" | |||
raise TypeError(f"cannot perform {name} with type {self.dtype}") | |||
|
|||
def __hash__(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may want to add some text to the top of the EA that says EA by default are not hashable
thanks @jbrockmendel |
This turns out to be a blocker for some cleanup in index.pyx