API: Remove zero names from dtype aliases#24807
Conversation
seberg
left a comment
There was a problem hiding this comment.
Looks fine to me, not sure I am use dto black style in C code yet, but doesn't matter...
int0 going to intp (IIRC) is rather confusing, but I don't understand what the point of these ever were and this was already pretty much deprecated.
Anyway, happy with this, unless someone points out that this is used a lot downstream and I really doubt that here.
rgommers
left a comment
There was a problem hiding this comment.
LGTM, let's give this a go - thanks Mateusz & reviewers!
| 'bool', 'object', | ||
| 'str', 'bytes', ('a', 'bytes_'), | ||
| ('int0', 'intp'), ('uint0', 'uintp')] | ||
| 'bool', 'object', 'str', 'bytes', ('a', 'bytes_')] |
There was a problem hiding this comment.
np.dtype('a') also seems ripe for removal, never seen it before and looks very odd. Does anyone know where that came from?
There was a problem hiding this comment.
I've actually noticed np.dtype('a') but I couldn't figure out its origin and purpose 😄 - therefore I decided to keep it.
There was a problem hiding this comment.
Looks like this goes back to 9ac3b0e. I have no idea why Travis added it and I don't know whether issues from the old trac issue tracker are still visible somewhere. Github search only finds 12 code usages of "np.dtype('a')". I say remove it.
There was a problem hiding this comment.
Presumably it is meant to mean "ascii"... if almost nobody uses, it shouldn't matter, unlik "c" it dosn't eve have a special meaning.
|
Am I to understand that these will be removed in NumPy v2.0? Or will it happen in a v1.x release? |
These changes are planned for NumPy 2.0 release. Here you can find all PRs with 2.0 changes label. |
Hi @rgommers @ngoldbaum @seberg,
This PR removes 7 names from the
np.dtype(<str_alias>)search:as these have been deprecated in #22607 in 1.24 release. Their
np.*types counterparts have been already removed from the main namespace.For informational purposes I added
ifcheck in the C code that explicitly verifies if one of these names is provided to display a custom error message. I'm not sure how much overhead such additional check will have onnp.dtypebut it's only evaluated when the execution is going to fail anyway withdata type *** not understood.