DEPR: Change .ix DeprecationWarning -> FutureWarning #26438
Conversation
jorisvandenbossche
added
Indexing
Codecov Report
@@ Coverage Diff @@
## master #26438 +/- ##
==========================================
- Coverage 91.73% 91.72% -0.01%
==========================================
Files 174 174
Lines 50741 50741
==========================================
- Hits 46548 46544 -4
- Misses 4193 4197 +4
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #26438 +/- ##
==========================================
- Coverage 91.73% 91.72% -0.01%
==========================================
Files 174 174
Lines 50741 50741
==========================================
- Hits 46548 46544 -4
- Misses 4193 4197 +4
Continue to review full report at Codecov.
|
|
Checked some of the logs, and I don't think there are remaining warnings un-catched. |
| @@ -255,6 +255,7 @@ Other API Changes | |||
| Deprecations | |||
| ~~~~~~~~~~~~ | |||
|
|
|||
| - The deprecated ``.ix[]`` indexer now raises a more visible FutureWarning instead of DeprecationWarning (:issue:`26438`). | |||
There was a problem hiding this comment.
double backticks on FutureWarning & DeprecationWarning. I would consider making this into a sub-section note and/or add to the headlines to make more visible.
| @@ -1137,40 +1137,40 @@ def test_ix_align(self): | |||
| df = df_orig.copy() | |||
|
|
|||
| with catch_warnings(record=True): | |||
There was a problem hiding this comment.
I think we should change these to assert_produces_warning(FutureWarning) as its more consistent with our style (could be a followup too)
There was a problem hiding this comment.
i'm not so sure.. shouldn't we only require assert_produces_warning for a test that specifically tests that the warning is raised (preferably with a message check) and use @pytest.mark.filterwarnings for all the tests where it's encountered?
There was a problem hiding this comment.
we are inconsistent in the code base for sure. but I think we mostly use assert_produces_warning, meaning if we suddently took out the warning (or changed it), these should fail. checking the test of the message is ok maybe in a single case (otherwise this is overkill)
There was a problem hiding this comment.
yeah... i think we do agree, i.e. that with catch_warnings should not be used and replaced with either assert_produces_warnings or @pytest.mark.filterwarnings. maybe a different viewpoint on which and how often each are used?
There was a problem hiding this comment.
Whatever the discussion / decision what is best here (for new code), I don't think it is worth updating code that we won't touch until we remove it in some months / next year.
On the actual discussion, I think indeed rather the filterwarnings with pytest is the way to go for those nowadays (certainly if you need to apply it to a lot of existing cases). Of course in addition to a few tests with assert_produces_warning to actually test the warning.
There was a problem hiding this comment.
Whatever the discussion / decision what is best here (for new code), I don't think it is worth updating code that we won't touch until we remove it in some months / next year.
agreed. as @jreback said, could be a follow-up. I don't mind looking into that.
There was a problem hiding this comment.
could be a follow-up. I don't mind looking into that.
You are free to spend your time how you want of course ;-) but I personally don't think it is worth the time. We will be removing this code shortly anyhow. There are plenty of other testing related things that are more useful IMO.
And wanted to suggest: like documenting our standard what to do in those case, but it is actually already quite good documented: http://pandas-docs.github.io/pandas-docs-travis/development/contributing.html#testing-warnings (and so exactly how you suggested it above)
There was a problem hiding this comment.
i'll need to check, but from memory I think .ix is used in a few tests to generate the expected result for testing the other indexers.
So maybe the first step would be to eliminate these, (would need to be done before .ix deprecation anyway). This would allow the removal of some catch_warnings.
I would guess that in theory it should be possible to remove all .ix occurrences from test files outside the test_ix module.
There was a problem hiding this comment.
yep that would be great; best to just use iloc for the expected
|
thanks @jorisvandenbossche |
This has been removed in pandas 1.0.0 (see pandas-dev/pandas#26438)
closes #15152