-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
DEPR: remove Panel-specific parts of core.indexing #25567
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #25567 +/- ##
==========================================
+ Coverage 91.26% 91.31% +0.05%
==========================================
Files 173 173
Lines 52966 52928 -38
==========================================
- Hits 48337 48329 -8
+ Misses 4629 4599 -30
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #25567 +/- ##
==========================================
+ Coverage 91.77% 91.83% +0.06%
==========================================
Files 174 174
Lines 50681 50643 -38
==========================================
- Hits 46513 46510 -3
+ Misses 4168 4133 -35
Continue to review full report at Codecov.
|
@@ -693,7 +686,6 @@ def ravel(i): | |||
sum_aligners = sum(aligners) | |||
single_aligner = sum_aligners == 1 | |||
is_frame = self.obj.ndim == 2 | |||
is_panel = self.obj.ndim >= 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are going to need a new error if self.obj.ndim.ndim > 2 (e.g. a numpy array); need to check both for setting & getting (it *might be already there but not sure about tests)
can you merge master; also created #25632 for things like this |
merged master to remove overlap with #25675 |
pandas/_libs/indexing.pyx
Outdated
@@ -20,4 +20,5 @@ cdef class _NDFrameIndexerBase: | |||
ndim = self._ndim | |||
if ndim is None: | |||
ndim = self._ndim = self.obj.ndim | |||
assert not ndim > 2, 'Internal Error: NDFrameIndexer ndim > 2' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this ever raised in user code? what happens when a 3-d indexer is passed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add some sort of test for this (also this should raise a ValueError if its user code)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this ever raised in user code? what happens when a 3-d indexer is passed?
added some tests for 3d indexing (integer ndarray only at the moment). not sure if this was what was required. tests is messy with mixture of some getting and setting not raising and those that raise produce a range of error messages.
can you add some sort of test for this (also this should raise a ValueError if its user code)
will look into this next.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also this should raise a ValueError if its user code
since NDFrame is not part of the API, i'm not sure how this can be raised from user code. (other than Panel)
i've added a test for NDFrame initialized with 3d array, but it only raises this exception with .ix
lambda i: DataFrame( | ||
np.random.randn(len(i), len(i)), index=i, columns=i) | ||
], ids=['Series', 'DataFrame']) | ||
@pytest.mark.parametrize('idxr, idxr_id', [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be worth making these a fixture at somepoint (the iteration over indexers)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the iteration over indexers
yeah. i appreciate we have duplication of parameterization at the moment, and fixtures may be of use. didn't carry on down that route at the moment as i wasn't sure if these tests were what was required.
separately for iteration over the indexes:
xref #25748 (comment). There is a indices
fixture in pandas\tests\indexes\conftest.py
. Maybe worth promoting that up a level so that it can also be used in pandas\tests\indexing
"unhashable type: 'numpy.ndarray'" # TypeError | ||
) | ||
|
||
if (isinstance(obj, Series) and idxr_id == 'getitem' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ugg this is why getitem is so complicated.
can you merge master. code change looks good, can you simplify the tests at all? maybe split them up a bit? |
can you merge master |
@simonjayhawkins can you merge master and update |
@simonjayhawkins can you merge master and fix up again? I think this should take a pretty big chunk out of what remains for Panel |
i've fixed up This now is basically a regression test. it does check the new error message added within this PR for .ix only. For the other indexers, other errors are raised before it gets to the deferred ndim lookup in indexing.pyx
the tests are already split by getting and setting, but as the parametrisation is also across indexes, pandas object types, and indexer that results in 88 test cases in each of the two tests. the reason parametrisation was used is to check for consistency of error messages raised. The error messages are not consistent at the moment and some permutations don't raise (they probably should as the output is some cases is non nonsensical). will need to raise some issues here to make the behavior more consistent. This results in tests that are visually messy. So again, if they should be split again, probably best to split on indexer? |
ok looks better ping on green |
@jreback pinging on green. |
thanks! |
follow-on from #25550