DEP: Remove deprecated numeric types and deprecate remaining #16554
Conversation
numpy/core/_type_aliases.py
Outdated
|
|
||
| # Add deprecated numeric-style type aliases manually, at some point | ||
| # we may want to deprecate the lower case "bytes0" version as well. | ||
| for name in ["Bytes0", "Datetime64", "Str0", "Uint64"]: |
There was a problem hiding this comment.
Why specifically these ones?
There was a problem hiding this comment.
I looked at the diff between before and after these changes. And those were all the remaining ones, so I figured we might as well deprecate them as well... It seems weird to me to get rid of Timedelta, but keep Datetime.
3bb2d80 to
79b6cbc
Compare
|
For everyone, the difference between You see that which is the ones I added to be deprecated now. |
79b6cbc to
b162875
Compare
| for name in ["Bytes0", "Datetime64", "Str0", "Uint64"]: | ||
| if name == "Uint64" and "uint64" not in allTypes: | ||
| # Due to the integer priority, this was not always defined | ||
| continue |
There was a problem hiding this comment.
This if is weird, but it failed tests and I think it is correct... if anyone has a 32bit linux or maybe windows to see that Uint64 was never included in np.typeDict on old versions, that would be good.
There was a problem hiding this comment.
It now passes tests, is this comment outdated?
There was a problem hiding this comment.
No, I worked around it. But, I now realized on windows we probably had a stray Uint32 and that will be missing now...
There was a problem hiding this comment.
np.typeDict has UInt64 on 1.16, windows 32 bit:
>>> sys.version
'2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit (Intel)]'
>>> np.typeDict['UInt64']
<type 'numpy.uint64'>
>>> np.__version__
1.16.6
>>>
There was a problem hiding this comment.
The capitalized UInt form has already been deprecated - it's just the weird Uint form that isn't.
It looks to me like I added this type accidentally as part of giving [np.cint, np.int_, np.longlong] unique names. On numpy 1.11.0 (and python 2.7) the name isn't there at all:
>>> numpy.__version__
'1.11.0'
>>> sorted(k for k in numpy.typeDict.keys() if isinstance(k, str) and k[0].isupper() and len(k) > 2)
['Bool', 'Complex128', 'Complex32', 'Complex64', 'Datetime64', 'Float128', 'Float16', 'Float32', 'Float64', 'Int16', 'Int32', 'Int64', 'Int8', 'Object0', 'String0', 'Timedelta64', 'UInt16', 'UInt32', 'UInt64', 'UInt8', 'Unicode0', 'Void0']So I think we can just remove this special case?
There was a problem hiding this comment.
Oh, that makes it more recent. I think we could just remove it, but if we want to get rid of Datetime64 as well, I also don't see a real downside to just including it here...
There was a problem hiding this comment.
for reference - the Uint64 name comes from uintp, due to these lines (97a2950#r39808190) in 1.16.
So on 32-bit platforms, there will be a Uint32 instead.
Let's either deprecate both or remove both.
There was a problem hiding this comment.
OK, I included Uint32, I think if the tests all pass things should be fine.
This removes the types from usage for `np.dtype()`, since the
two are closely related, also finishes the deprecation of
`typeNA` and `sctypeNA` (thus removing them from the public API).
The deprecation for the numeric types was only shown for
`np.dtype("Complex64")`, etc. however, here they are also
removed from `np.typeDict` and `np.sctypeDict`.
b162875 to
d4f9fb7
Compare
|
|
||
| from numpy.compat import unicode | ||
| from numpy._globals import VisibleDeprecationWarning | ||
| from numpy.core._string_helpers import english_lower, english_capitalize |
There was a problem hiding this comment.
Is english_capitalize used any more?
There was a problem hiding this comment.
No, I hardcoded the few exceptions...
There was a problem hiding this comment.
My point is, can its definition be removed too?
There was a problem hiding this comment.
Sorry for being unclear, yes it can be, there are no more usages in this file.
There was a problem hiding this comment.
@eric-wieser one quick question to be sure. Uin32 was never defined on windows? Because otherwise I have to check for (and add it) here... (or remove both)
There was a problem hiding this comment.
Uint32 was defined on 32-bit windows only.
There was a problem hiding this comment.
Ahh, its a 32bit thing... In any case, will fix this up then.
Cool about gh-14882 seems there is consensus on moving forward with it, so I will definitely review and put that in soon!
There was a problem hiding this comment.
Sorry for being unclear, yes it can be, there are no more usages in this file.
Ping on this - we may as well remove it from _string_helpers if it has no other callers.
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
| ] | ||
| deprecated_types = ['Bytes0', 'Datetime64', 'Str0'] | ||
| # Depending on intp size, either Uint32 or Uint64 is defined: | ||
| deprecated_types.append(f"U{np.dtype(np.intp).name}") |
There was a problem hiding this comment.
Or
| deprecated_types.append(f"U{np.dtype(np.intp).name}") | |
| deprecated_types.append(np.dtype(np.uintp).name.title()) |
There was a problem hiding this comment.
Looks nicer, I am a bit uncertain about locales here since the other code used english_upper everywere?
There was a problem hiding this comment.
Good point, safer to leave it as is.
|
Thanks, will these changes end up in NumPy 1.19 or 1.20? |
|
1.20, no intention to backport this, 1.19 may still get more critical fixes, this is not critical. |
This removes the types from usage for
np.dtype(), since thetwo are closely related, also finishes the deprecation of
typeNAandsctypeNA(thus removing them from the public API).The deprecation for the numeric types was only shown for
np.dtype("Complex64"), etc. however, here they are alsoremoved from
np.typeDictandnp.sctypeDict.