-
-
Notifications
You must be signed in to change notification settings - Fork 10.5k
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
BUG: issubdtype is inconsistent on types and dtypes #9505
Conversation
However, if you actually look at that file, it seems to not be related to numerictypes.py at all |
6b9830f
to
d602521
Compare
Yeah, the numpy type hierarchy is a mess. Not conceptually, but as implemented. There are things like
that, IMHO, should raise errors. Perhaps we should make things like |
I've thought about this patch some more, and decided the best approach is just to fix dtype inputs, and |
They already are not creatable - |
42b84a5
to
1517171
Compare
@charris: See updated PR. Apart from the DEP commit, which I can split off if needed, I don't think this needs a mailing list consultation |
# float, and similar less obvious things, such as np.generic from | ||
# basestring | ||
mro = arg2.mro() | ||
arg2 = mro[1] if len(mro) > 1 else mro[0] |
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.
Note the only way that len(mro) == 1
is if arg2 is object
, which should never happen - but we had it before too, so...
1517171
to
6b191cd
Compare
numpy/core/numerictypes.py
Outdated
warnings.warn( | ||
"Conversion of the second argument of issubdtype from `{raw}` " | ||
"to `{abstract} is deprecated. In future, it will be treated as " | ||
"`{concrete} == np.dtype({raw}).type`.".format( |
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.
Example message:
In [1]: np.issubdtype(complex, bytearray)
True
FutureWarning: Conversion of the second argument of issubdtype from
bytearray
tonp.generic
is deprecated. In future, it will be treated asnp.object_ == np.dtype(bytearray).type
.
A quick search reveals that matplotlib makes the This will also catch out people who wrote |
c666800
to
1e06594
Compare
LGTM. Could you add an entry in the release notes under |
Happy to rebase this myself later. |
The test queue looks stuffed. Yeah, go ahead and fix things up and add the release note. |
Close and reopen to see if the tests restart. |
…ation Fixes numpygh-9506, unsigned exponentiation
In many cases, this coercion is surprising, or would be if the user knew about it: * [('a', int)] -> np.flexible * str - > str (!) - not even a numpy type * 'float32' -> np.floating (discards size) * int -> np.signed_integer (not np.integer, as is usually meant)
7ccc47d
to
091b8c3
Compare
Thanks Eric. |
Numpy is deprecating this usage (see numpy/numpy#9505).
Fixes issue #419 that prompts a FutureWarning due to a numpy change (as can be seen in numpy/numpy#9505)
Fix future warning on use of `np.issubdtype`. Fixes: ``` /home/travis/build/nipy/dipy/venv/lib/python3.4/site-packages/nibabel/streamlines/array_sequence.py:23: FutureWarning: Conversion of the second argument of issubdtype from `bool` to `np.generic` is deprecated. In future, it will be treated as `np.bool_ == np.dtype(bool).type`. ``` observed in projects using Nibabel, e.g. DIPY: https://travis-ci.org/nipy/dipy/jobs/471947136 More information about the issue and the fix at: numpy/numpy#2334 numpy/numpy#9505
Fix future warning on use of `np.issubdtype`. Fixes: ``` /home/travis/build/nipy/dipy/venv/lib/python3.4/site-packages/nibabel/streamlines/array_sequence.py:23: FutureWarning: Conversion of the second argument of issubdtype from `bool` to `np.generic` is deprecated. In future, it will be treated as `np.bool_ == np.dtype(bool).type`. ``` observed in projects using Nibabel, e.g. DIPY: https://travis-ci.org/nipy/dipy/jobs/471947136 More information about the issue and the fix at: numpy/numpy#2334 numpy/numpy#9505
This finishes the deprecation started in numpygh-9505 removing behaviour that allowed strings/types representing specific dtypes to behave like their more generic supertypes (e.g. the python float would map to floating instead of float64 which it typically maps to).
This finishes the deprecation started in gh-9505 removing behaviour that allowed strings/types representing specific dtypes to behave like their more generic supertypes (e.g. the python float would map to floating instead of float64 which it typically maps to). Co-Authored-By: Eric Wieser <[email protected]>
Previously, issubdtype(x, y) and issubdtype(dtype(x), dtype(y)) could give different results
Fixes #9480 and #9506 and #2334 (duped by #5711 and #3218)
This deprecates all of the following strange behaviors, with the intent in the distant future to invert the results: