BUG: treat nan-objects the same way float64-nans are treated - all na… #22207
Conversation
…ns are from the same equivalence class
asv_benchmark:
|
gfyoung
added
Missing-data
…ch assumed differently
Codecov Report
@@ Coverage Diff @@
## master #22207 +/- ##
==========================================
+ Coverage 92.06% 92.06% +<.01%
==========================================
Files 169 169
Lines 50694 50698 +4
==========================================
+ Hits 46671 46676 +5
+ Misses 4023 4022 -1
Continue to review full report at Codecov.
|
| @@ -1661,9 +1662,13 @@ def test_isin_nan_common_object(self, nulls_fixture, nulls_fixture2): | |||
| # Test cartesian product of null fixtures and ensure that we don't | |||
| # mangle the various types (save a corner case with PyPy) | |||
|
|
|||
| if PYPY and nulls_fixture is np.nan: # np.nan is float('nan') on PyPy | |||
| # all nans are the same | |||
There was a problem hiding this comment.
so this test seems now very restrictive?
There was a problem hiding this comment.
did you remove the PYPY on purpose?
There was a problem hiding this comment.
cc @mattip can you comment on the equivalence of nulls here? we don't test on PYPY, can you see if this still fails?
There was a problem hiding this comment.
@jreback After the fix the behavior is less subtle:
Index([nulls_fixture]).isin([nulls_fixture2])
is always True as long as nulls_fixture and nulls_fixture2 are nans, no matter whether those are the same nan-objects or different nan-objects. Thus PyPy is no longer a special case. But I must confess, I didn't test with PyPy and assumed this would be done somewhere in CI.
It seems as if the purpose of this test is to check, that the identity of the object is preserved (something similar to bug #22160). In this case np.nan is no longer a good tool to do this check, because isin bcomes agnostic to the exact identity of the nan-object.
There was a problem hiding this comment.
will check it on PyPy, thanks for the heads up.
There was a problem hiding this comment.
this particular test in its 25 variants passes on PyPy. There are other failures but they seem unrelated.
…s adjusting the test cases
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
it is more or less the clean-up after PR pandas-dev#21904 and PR pandas-dev#22207, the underlying hash-map handles all cases correctly out-of-the box and thus no special handling is needed.
…ns are from the same equivalence class (GH22119)
git diff upstream/master -u -- "*.py" | flake8 --diff