Deprecating python type aliases (np.int, np.long, np.str, ...)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecating python type aliases (np.int, np.long, np.str, ...)

Sebastian Berg
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/02def703b8b7b28ed315a658808364fd024bb45c
(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_`
==================  =====================  ==========================



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating python type aliases (np.int, np.long, np.str, ...)

Sebastian Berg
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/02def703b8b7b28ed315a658808364fd024bb45c
> (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_`
> ==================  =====================  ==========================
>
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment