Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MNT: Bump dev pin on NumPy #60987
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
MNT: Bump dev pin on NumPy #60987
Changes from 9 commits
658c4d5
e424a96
912bc1b
e75abfe
856a52f
a8304b6
41265f3
9c2f5ac
f6a2330
83e2644
8fd50b4
f7ef882
347b865
17ec834
65e1374
14d34a7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 merged #54268 a while back to make these reprs render like the Python scalars/pre numpy 2.0. It appears that PR didn't touch all the relevant repr methods
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'll do a precursor to fix the reprs for arrays, and then revert some of the outputs here.
Your comment only applies to EA reprs?
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 would say any repr in pandas shouldn't be showing the NEP 51 style repr for scalars.
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 main motivation behind NEP 51 is that the Python numerical types behave differently from the NumPy scalars.
They give a few examples such as
So I think we should be showing the NEP 51 style repr for scalars.
@mroeschke you have approved this PR so I assume that was a typo?
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.
NEP 51 is for the output of numpy scalars to help users distinguish the NumPy scalars from the Python builtin types and clarify their behavior and that array representation will not be affected since it already includes the dtype= when necessary.
So should probably change the example here to not use the NEP 51 repr in the output?
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 agree with Simon. Historically I don't think we have ever favored exposing NumPy scalars directly to end users. If that has happened as an implementation detail that is one thing, but explicitly showing that to an end user runs counter to what we have done in the psat
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.
Updated.
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.
There are a few of these where I'm wondering if we should be returning Python scalars instead of NumPy. Should issues be opened for these?
cc @pandas-dev/pandas-core
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 generally we always want to return Python scalars (IIRC we got a lot of issues about this in iteration and iteration-like APIs in the past)
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.
Even just wrapping the result of
Series._reduce
withmaybe_box_naive
breaks 692 tests. From a cursory look, they're tests that are expecting a NumPy scalar back. A lot however are something likeop(data).any().any()
so that they will work with DataFrame and Series. I plan to bring this up in the next dev meeting.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 agree we should always return Python scalars. I'm surprised at the amount of failures that expect NumPy scalars
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'd think you need a deprecation on this, because people may have code that depends on the result being a numpy scalar. I think that the tests we have in
pandas-stubs
for typing may depend on this.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.
We could put it up behind a
future
option, maybe something likealways_return_python_scalars