The errors are due to the deprecation warnings being turned into errors in the tests. How was it that one is supposed to deal with that? If I try the offending test in a console with this PR built I get:

In [4]: np.dtype('Bool')
/Users/jaimefrio/miniconda/envs/numpydev/bin/ipython:1: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
  #!/bin/bash /Users/jaimefrio/miniconda/envs/numpydev/bin/python.app
Out[4]: dtype('bool')

We have a deprecated decorator in the testing.decorators that should work (it should set deprecation warnings to "always" and then check that one is being raised).

Though I guess if the test does nothing else, could also just remove it, and comment on the deprecation test that it should be made an error test when done (which we would probably do anyway).

Ohhh, sorry :(. I misread it, the Deprecation test does not work. Thought there was some other test that did not work.

The deprecation test will also check the error case. You will have to pass in the exceptions=(DeprecationWarning,) argument to assert_deprecated (or just not use assert_deprecated). And set it to TypeError.
As default the test expects the error (if you set the warning to raise) to be a DeprecationWarning.

Needs to be mentioned in release notes. I expect this will also impact some old code, possibly in astropy that inherited pyfits, so it might be a good idea to post it on the list for comment.

In fact, none of these types seem present in current numpy nor turn up in a search. I suspect they went away with the numarray compatibility module.

Looks like they were difined in numpy/numarray/numerictypes.py, which is no longer around.

NVM, they to still seem recongnized by some routines. Somehow my first check didn't turn them up...

I had trouble hunting them down myself, but they are added to the type dictionary in the _add_aliases function in numerictypes.py. I made that info part of the test comment so that we know where to look for them when we complete the deprecation.

Another possibility here is to set up a parallel dictionary of deprecated types in numpy.core._internal and import that with npy_cache_import, then after an object is found, check if it is also in the deprecated dictionary. Importing it directly gets around having another function to set it.

I suspect an error in the code.

Fixed up in #7743, so closing. Thanks Jaime.

☔ The latest upstream changes (presumably #7747) made this pull request unmergeable. Please resolve the merge conflicts.

Sorry for bumping this old issue. What's the expected future behavior for

In [9]: np.dtype("int") == "Int64"
/Users/taugspurger/miniconda3/envs/travis-37-numpydev/bin/ipython:1: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
  #!/Users/taugspurger/miniconda3/envs/travis-37-numpydev/bin/python

Will that raise, or return False?

This is probably the wrong place to bring this up, but I'm not sure on the "right" place. By mistake in some Pandas timing code I recently wrote np.zeros(10).astype('Int64') thinking I'd get a Pandas Int64 (nullable int) object. Instead I got a numpy int64 with the above DeprecationWarning.

Of course I shouldn't expect to get a Pandas object (I was mixing Pandas and NumPy timing code) but I didn't expect to get a different dtype to the one I was after.

I suspect now that Pandas supports Nullable Int64-Int8 some other users might mistakenly type these in to NumPy and get the same error I had. Maybe it is time to accelerate the DeprecationWarning? Or maybe warn the user that there is a name conflict to Pandas which might be what they were after?

• https://pandas.pydata.org/pandas-docs/stable/user_guide/integer_na.html

@ianozsvald yes you are right, the deprecation warning was added in 2016, we can definitely just remove it in master. Want to have a look?

That's good to hear. Sorry, I'll decline doing any work, between having a baby on the way, upcoming open source conference talks and a pydata conference to help organise I'm not taking on any additional jobs. Maybe this could take on a tag for something like "good first time issue"?

Sure, I just always ask. It would have been a bit more complicated than an easy-fix anyway probably, so opened gh-16554 instead. Thanks.

It is sensible to ask :-) Thanks for pushing it on. The work of all of you maintainers is much appreciated!