-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Hashable DataFrames #3882
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
Comments
i've been thinking about this off and on. a somewhat related issue is that of the empty frame, i.e., |
|
|
yes..you are right...oh well my argument is bad then! |
Ah, you're right, I didn't even check series, it's just DataFrame which should raise. Easy fix (raise |
could implement this for indices...thoughts? |
in that case u should probably hash the name, number of levels, class, and dtype |
still have the mutability issue though I suppose if the user accepts this it would be nice to deal with it I would table to 0.12 for now |
So, at the moment I've put this in NDFrame. Maybe it should go in PandasObject, and then have objects which should hash override it (like if we can get indices to hash using that clever method). Are there any besides Index/MultiIndex? |
i vote for default to not hashable. better to alert the user to non-hashability rather than possibly giving misleading ideas about the hashability of things |
agree....not hashability is/should be default until we change API |
ok I've moved it to PandasObject, removes repeated code too. :) |
See this SO answer, they want to use memoisation.
OP points out this gets different results from (presumably it does it off id)
Should they be hashable or should hash raise? (does it defeat the point of hashing if hashing is expensive?) cc @cpcloud
The text was updated successfully, but these errors were encountered: