Deprecating python type aliases (np.int, np.long, np.str, ...)
Hi all, In the pull request: https://github.com/numpy/numpy/pull/14882 Eric proposes to deprecate the type aliases which NumPy imports into its main namespace (e.g. np.int, np.bool, see table below [1]). Right now there seems to be a consensus to move this forward and I plan on doing that, so this is a heads-up in case anyone has a differing opinion. The deprecation should not be very noisy as such, but I expect it will require many projects to update their code in the long run (although the changes are very simple). One advantage is that some aliases are confusing, e.g. `np.float` is Python float, and thus actually a `float64` and not a C `float`, which is a `float32`. For an example of how this affects a code-base, this is SciPy: https://github.com/scipy/scipy/pull/12344/commits/02def703b8b7b28ed315a65880... (A chunk of the full PR unrelated style fixes). Cheers, Sebastian [1] Full table of deprecated aliases: ================== ===================== ============================ Deprecated Equivalent to Possibly intended numpy type ================== ===================== ============================ ``numpy.bool`` ``bool`` `numpy.bool_` ``numpy.int`` ``int`` `numpy.int_` (default int dtype), `numpy.cint` (C ``int``) ``numpy.float`` ``float`` `numpy.float_`, `numpy.double` (equivalent) ``numpy.complex`` ``complex`` `numpy.complex_`, `numpy.cdouble` (equivalent) ``numpy.object`` ``object`` `numpy.object_` ``numpy.str`` ``str`` `numpy.str_` ``numpy.long`` ``numpy.compat.long`` `numpy.int_` (C ``long``), `numpy.longlong` (largest integer type) ``numpy.unicode`` ``numpy.compat.str`` `numpy.unicode_` ================== ===================== ==========================
On Thu, 2020-06-11 at 09:59 -0500, Sebastian Berg wrote:
Hi all,
In the pull request: https://github.com/numpy/numpy/pull/14882 Eric proposes to deprecate the type aliases which NumPy imports into its main namespace (e.g. np.int, np.bool, see table below [1]).
Right now there seems to be a consensus to move this forward and I plan on doing that, so this is a heads-up in case anyone has a differing opinion.
The deprecation should not be very noisy as such, but I expect it will
Sorry, I made a mistake when considering the implementation. It may be fairly noisy, but it is also very easy to avoid for the user.
require many projects to update their code in the long run (although the changes are very simple).
One advantage is that some aliases are confusing, e.g. `np.float` is Python float, and thus actually a `float64` and not a C `float`, which is a `float32`.
For an example of how this affects a code-base, this is SciPy: https://github.com/scipy/scipy/pull/12344/commits/02def703b8b7b28ed315a65880... (A chunk of the full PR unrelated style fixes).
Cheers,
Sebastian
[1] Full table of deprecated aliases:
================== ===================== ========================== == Deprecated Equivalent to Possibly intended numpy type ================== ===================== ========================== == ``numpy.bool`` ``bool`` `numpy.bool_` ``numpy.int`` ``int`` `numpy.int_` (default int dtype), `numpy.cint` (C ``int``) ``numpy.float`` ``float`` `numpy.float_`, `numpy.double` (equivalent) ``numpy.complex`` ``complex`` `numpy.complex_`, `numpy.cdouble` (equivalent) ``numpy.object`` ``object`` `numpy.object_` ``numpy.str`` ``str`` `numpy.str_` ``numpy.long`` ``numpy.compat.long`` `numpy.int_` (C ``long``), `numpy.longlong` (largest integer type) ``numpy.unicode`` ``numpy.compat.str`` `numpy.unicode_` ================== ===================== ==========================
participants (1)
-
Sebastian Berg