-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
API: Cleaning numpy/__init__.py
and main namespace - Part 5 [NEP 52]
#24587
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
API: Cleaning numpy/__init__.py
and main namespace - Part 5 [NEP 52]
#24587
Conversation
It looks like pandas needs to be updated for the doc build to pass. It also looks like the repr for
|
7dad0c1
to
b229e45
Compare
* based on numpy/numpy#24587: * replace the single usage of `np.recarray` I found in our codebase--there are references to third-party libraries providing us with `recarray` that I haven't touched * similar PRs have been merged to `pandas` and `scipy` [skip cirrus]
* based on numpy/numpy#24587: * replace the single usage of `np.recarray` I found in our codebase--there are references to third-party libraries providing us with `recarray` that I haven't touched * similar PRs have been merged to `pandas` and `scipy` [skip cirrus]
b229e45
to
a622a12
Compare
Can we actually do this? It looks to me like |
@rgommers These are used but the change to move to I think we have three options:
What do you think about these options? Which should I go with? |
Yes, that'd be a little unfortunate. However, I'm not sure it's really that black-and-white. For all functions/objects we should have one documented/preferred location, but for some other popular functions we've also decided to leave a compatibility shim in place. For For |
If taking it out of the main namespace would be too disruptive it should stay, practicality beats purity. That said, a user-visible deprecation warning in NumPy 2.0 with a plan to remove it in a few versions also makes sense I think. |
bbf20e2
to
668edfa
Compare
Hi @rgommers @ngoldbaum, I updated this PR according to your feedback:
|
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.
While we may not be deprecating np.recarray
, I think it would still make sense to change its repr, in this PR I have:
In [3]: np.recarray
Out[3]: numpy.recarray
Whereas I would expect it to be an alias to numpy.rec.recarray
now rather than the other way around.
Use ``np.char.compare_chararrays`` instead. | ||
|
||
* ``np.chararray`` has been deprecated and it will be removed in the future. | ||
Use ``np.char.chararray`` instead. |
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 I would rephrase this slightly as "The charrarray
in the main namespace has been deprecated. It can be imported without a deprecation warning from np.char.chararray
for now, but we are planning to fully deprecate and remove chararray
in the future.", since I think the intention is to fully deprecate it and remove it, we just haven't actually done the work yet, so can't outright remove it now. I proposed doing those deprecations before NumPy 2.0 as part of NEP 55, but that hasn't fully gone through yet. If that happens before NumPy 2.0, I will update this release note.
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.
Sure! I updated this change note.
numpy/__init__.py
Outdated
warnings.warn( | ||
"`np.chararray` is deprecated and will be removed from " | ||
"the main namespace in the future. Use `np.char.chararray` " | ||
"instead.", DeprecationWarning, stacklevel=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.
For the migration, I would say "Use an array with a string or bytes dtype instead," while it will still be available as np.char.charray
, that will likely also be deprecated before NumPy 2.0 is released.
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.
Sure! Updated.
@ngoldbaum I decided to keep repr as Should I change |
I personally think changing the canonical location makes sense and is in the spirit of the other changes we're making for the API migration. Feel free to wait for others to weigh in. |
927f062
to
eb6a10a
Compare
Makes sense to me - I updated the repr to |
Thanks so much for your diligence on pushing forward refactoring the main namespace @mtsokol! |
Relevant issue: #24306
Scope of the PR:
compare_chararrays
as it comes from a legacy module. It's still available asnp.char.compare_chararrays
.RemoveDeprecatechararray
as it comes from a legacy module. It's still available asnp.char.chararray
.format_parser
as it's the only function fromrec
present in the main namespace. It's still available asnp.rec.format_parser
.Removerecarray
. It's still available asnp.rec.recarray
.