-
Notifications
You must be signed in to change notification settings - Fork 898
Add pandas 2.0 support #2585
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
Add pandas 2.0 support #2585
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2585 +/- ##
===========================================
+ Coverage 87.74% 99.47% +11.73%
===========================================
Files 393 403 +10
Lines 23271 24198 +927
===========================================
+ Hits 20419 24071 +3652
+ Misses 2852 127 -2725
|
primitive_func = self.primitive().get_function() | ||
given_answer = primitive_func(data) | ||
assert np.isclose(answer, given_answer, atol=0.01) | ||
if dtype == "float64": |
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.
This is not a blocker (more of an incidental comment), but seeing the if
clause here makes me consider if we should eventually refactor this test. Given that the previous data
objects are being cast to float64
dtype as well, and the test previously did not require if
clauses, it seems like there are three separate classes of behaviors here:
- How the kurtosis method handles the int64 dtype
- How the kurtosis primitive handles the float64 dtype when the data "looks like" an int64 (evidently this doesn't seem to differ from the previous class)
- How the kurtosis primitive handles the float64 dtype when the data are "true" floats
Separating those at some point might help to better document this primitive's behavior.
Add pandas 2.0 support
Closes #2532
Closes #2556