Skip to content

RangeIndex copy behaviour differs from other indices #12288

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
toobaz opened this issue Feb 11, 2016 · 5 comments
Closed

RangeIndex copy behaviour differs from other indices #12288

toobaz opened this issue Feb 11, 2016 · 5 comments
Labels
Bug Indexing Related to indexing on series/frames, not to indexes themselves
Milestone

Comments

@toobaz
Copy link
Member

toobaz commented Feb 11, 2016

It is my understanding that the copy parameter of RangeIndex is present virtually only for API compatibility with other indices: however the behaviour for copy=False differs from other indices in what follows:

In [2]: i = pd.Int64Index(range(10))

In [3]: i.name = 'original'

In [4]: j = pd.Int64Index(i)

In [5]: j.name

In [6]: j.name = 'copy'

In [7]: i.name
Out[7]: 'original'

In [8]: i = pd.RangeIndex(10)

In [9]: i.name = 'original'

In [10]: j = pd.RangeIndex(i)

In [11]: j.name
Out[11]: 'original'

In [12]: j.name = 'copy'

In [13]: i.name
Out[13]: 'copy'

In other words, since RangeIndex doesn't have any data to copy, the value of the copy parameter should be irrelevant. For homogeneity with other indices, we should always act as if copy=True. The docs should also be changed to state that copy parameter has no effect and is present only for API compatibility. I'll push a PR if you agree.

@jreback
Copy link
Contributor

jreback commented Feb 11, 2016

this is a bug in the constructor I think. It should match what Int64Index does.
It doesn't matter that RangeIndex doesn't have data to copy, it still should make a new index.

@jreback jreback added Bug Indexing Related to indexing on series/frames, not to indexes themselves Difficulty Intermediate labels Feb 11, 2016
@jreback jreback added this to the 0.18.0 milestone Feb 11, 2016
toobaz added a commit to toobaz/pandas that referenced this issue Feb 11, 2016
@jreback
Copy link
Contributor

jreback commented Feb 12, 2016

So Int64Index, Float64Index all have the same issue.
They are not propogating the name of a passed index on construction. That is the issue here.
RangeIndex actually is ok.

These look ok

In [6]: a = Index(list('abc'),name='foo')

In [7]: Index(a)
Out[7]: Index([u'a', u'b', u'c'], dtype='object', name=u'foo')
In [20]: i = Index(xrange(3),name='foo')

In [21]: i
Out[21]: RangeIndex(start=0, stop=3, step=1, name=u'foo')

In [22]: pd.RangeIndex(i)
Out[22]: RangeIndex(start=0, stop=3, step=1, name=u'foo')

While Int64Index does not

In [8]: i = Index(range(3),name='foo')

In [9]: Index(i)
Out[9]: Int64Index([0, 1, 2], dtype='int64', name=u'foo')

In [10]: pd.Int64Index(i)
Out[10]: Int64Index([0, 1, 2], dtype='int64')

@toobaz
Copy link
Member Author

toobaz commented Feb 12, 2016

I think we have 2 problems here: the one I reported and the one you now point at. If we fix the one you're pointing at, we will still have a difference that Int64Index(Int64Index(), copy=*) will create two indices no matter the value of copy, while RangeIndex(RangeIndex(), copy=False) will not, and this reflects in the impossibility of giving different names. So you're right in Int64Index & co. being buggy, but this doesn't have much to say on my PR.

@toobaz
Copy link
Member Author

toobaz commented Feb 12, 2016

Or to put it shortly: this test fails in master. I think it shouldn't. Do you agree? [Y/n]

@jreback
Copy link
Contributor

jreback commented Feb 12, 2016

ok, going to merge your fix, pls open a new issue for the Int64Index/Float64Index name issues I desrcribe above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Indexing Related to indexing on series/frames, not to indexes themselves
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants