Skip to content

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

Closed
jbrockmendel opened this issue May 18, 2020 · 6 comments
Closed

API: implement ObjectIndex to take place of Index #34238

jbrockmendel opened this issue May 18, 2020 · 6 comments

Comments

@jbrockmendel
Copy link
Member

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

@jbrockmendel jbrockmendel added Bug Needs Triage Issue that has not been reviewed by a pandas team member API Design and removed Bug Needs Triage Issue that has not been reviewed by a pandas team member labels May 18, 2020
@jorisvandenbossche
Copy link
Member

Are there advantages of this? (except being able to remove the ABC, which alone doesn't warrant such a change IMO)

@jbrockmendel
Copy link
Member Author

As mentioned in #34159, there are places in the code where we see an Index object and assume that it is object-dtype. This would make that assumption more explicit, and would allow #34159 to avoid running into it.

@TomAugspurger
Copy link
Contributor

there are places in the code where we see an Index object and assume that it is object-dtype

@jbrockmendel what do these checks look like? Is it type(obj) is pd.Index? Or more like an isinstance(obj, ABCIndex)?

IMO, adding an ObjectIndex feels like patching over an internals issue by exposing it to the end user.

@jbrockmendel
Copy link
Member Author

what do these checks look like? Is it type(obj) is pd.Index? Or more like an isinstance(obj, ABCIndex)?

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

@jorisvandenbossche
Copy link
Member

its more along the lines of methods in Index that are overridden by all extant subclasses assume its object dtype (or just non-EA).

But those places that assume that Index is object dtype would need to be updated anyhow, in context of #34159, or when introducing ObjectIndex ?
(it might be useful to give a concrete example, because now it's a bit vague discussion)

IMO, adding an ObjectIndex feels like patching over an internals issue by exposing it to the end user.

+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).

@jbrockmendel
Copy link
Member Author

And that is also the reason that I would prefer adding EA support in the base Index class instead of a new ExtensionIndex class

I'm still not wild about that, but we can discuss that separately. This idea clearly isn't gaining traction, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants