-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
API: implement ObjectIndex to take place of Index #34238
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
Are there advantages of this? (except being able to remove the ABC, which alone doesn't warrant such a change IMO) |
@jbrockmendel what do these checks look like? Is it IMO, adding an ObjectIndex feels like patching over an internals issue by exposing it to the end user. |
IIRC its more along the lines of methods in Index that are overridden by all extant subclasses assume its object dtype (or just non-EA). This is mostly relevant in the context of #34159 |
But those places that assume that Index is object dtype would need to be updated anyhow, in context of #34159, or when introducing ObjectIndex ?
+1. And that is also the reason that I would prefer adding EA support in the base Index class instead of a new ExtensionIndex class (certainly given that it would not have dtype-specific methods, like eg DatetimeIndex right now has, there doesn't seem to be much value to have a separate class for he user). |
I'm still not wild about that, but we can discuss that separately. This idea clearly isn't gaining traction, so closing. |
Then we would never actually return an Index object.
We could then make ABCIndex behave like ABCIndexClass, and get rid of the latter.
Briefly discussed in #34159
The text was updated successfully, but these errors were encountered: