Skip to content
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

CLN: Remove uses of Index._data #19658

Closed
TomAugspurger opened this issue Feb 12, 2018 · 3 comments
Closed

CLN: Remove uses of Index._data #19658

TomAugspurger opened this issue Feb 12, 2018 · 3 comments
Labels
Clean Closing Candidate May be closeable, needs more eyeballs Internals Related to non-user accessible pandas implementation Refactor Internal refactoring of code

Comments

@TomAugspurger
Copy link
Contributor

The type of Index._data is inconsistent across Index subclasses

class output
Index ndarray
PeriodIndex ndarray[int] (ordinals)
DatetimeIndex DatetimeIndex (?)
DatetimeIndex[tz] ndarray[datetime64[ns]]
CategoricalIndex Categorical
IntervalIndex None

We should replace uses of ._data with ._values or ._ndarray_values, which have more consistent behavior.

I don't think we can remove ._data entirely though. It's used for quickly setting values in some places. Haven't looked too closely though.

@TomAugspurger TomAugspurger added Refactor Internal refactoring of code Internals Related to non-user accessible pandas implementation Difficulty Intermediate Clean labels Feb 12, 2018
@TomAugspurger TomAugspurger added this to the Next Major Release milestone Feb 12, 2018
@jorisvandenbossche
Copy link
Member

I suppose that, once we have Array classes for all our own extension types, those _data attributes in principle (with some refactoring to get there) should be those arrays? And then, it should be the same as _values

@jbrockmendel
Copy link
Member

actionable/closeable? Now that we use _mgr instead of _data for BlockManager, foo._data is much less ambiguous

@jbrockmendel jbrockmendel added the Closing Candidate May be closeable, needs more eyeballs label Sep 22, 2020
@mroeschke
Copy link
Member

Agreed, the use of _mgr should make this more consistent now. Closing but happy to reopen if that's not the case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Clean Closing Candidate May be closeable, needs more eyeballs Internals Related to non-user accessible pandas implementation Refactor Internal refactoring of code
Projects
None yet
Development

No branches or pull requests

4 participants