Py-API: Deprecate `np.dtype(np.floating)` and similar dtype creation

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

Py-API: Deprecate `np.dtype(np.floating)` and similar dtype creation

Sebastian Berg
Hi all,

In https://github.com/numpy/numpy/pull/15534 I would like to start
deprecating creating dtypes from "abstract" scalar classes, such as:

np.dtype(np.floating) is np.dtype(np.float64)

While, at the same time, `isinstance(np.float32, np.floating)` is true.

Right now `arr.astype(np.floating, copy=False)` and, more obviously,
`arr.astype(np.dtype(np.floating), copy=False)` will cast a float32
array to float64.

I think we should deprecate this, to consistently enable that in the
future `dtype=np.floating` may choose to not cast a float32 array. Of
course for the `astype` call the DeprecationWarning would be changed to
a FutureWarning before we change the result value.

A slight (but hopefully rare) annoyance is that `np.integer` might be
used since it reads fairly well compared to `np.int_`. The large
upstream packages such as SciPy or astropy seem to be clean in this
regard, though (at least almost clean).

Does anyone think this is a bad idea? To me these deprecations seem
fairly straight forward, possibly flush out bugs/unintended behaviour,
and necessary for consistent future behaviour. (More similar ones may
have to follow).

If there is some, but not much, hesitation, I can also add this to the
NEP 41 draft. Although I currently feel it is the right thing to do
even if we never had any new dtypes.

- Sebastian

_______________________________________________
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: Py-API: Deprecate `np.dtype(np.floating)` and similar dtype creation

Nathan
For what it's worth, github search only finds two instances of this usage:


On Fri, Feb 14, 2020 at 2:28 PM Sebastian Berg <[hidden email]> wrote:
Hi all,

In https://github.com/numpy/numpy/pull/15534 I would like to start
deprecating creating dtypes from "abstract" scalar classes, such as:

np.dtype(np.floating) is np.dtype(np.float64)

While, at the same time, `isinstance(np.float32, np.floating)` is true.

Right now `arr.astype(np.floating, copy=False)` and, more obviously,
`arr.astype(np.dtype(np.floating), copy=False)` will cast a float32
array to float64.

I think we should deprecate this, to consistently enable that in the
future `dtype=np.floating` may choose to not cast a float32 array. Of
course for the `astype` call the DeprecationWarning would be changed to
a FutureWarning before we change the result value.

A slight (but hopefully rare) annoyance is that `np.integer` might be
used since it reads fairly well compared to `np.int_`. The large
upstream packages such as SciPy or astropy seem to be clean in this
regard, though (at least almost clean).

Does anyone think this is a bad idea? To me these deprecations seem
fairly straight forward, possibly flush out bugs/unintended behaviour,
and necessary for consistent future behaviour. (More similar ones may
have to follow).

If there is some, but not much, hesitation, I can also add this to the
NEP 41 draft. Although I currently feel it is the right thing to do
even if we never had any new dtypes.

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

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Py-API: Deprecate `np.dtype(np.floating)` and similar dtype creation

Sebastian Berg
On Fri, 2020-02-14 at 14:39 -0700, Nathan wrote:
> For what it's worth, github search only finds two instances of this
> usage:
>
> https://github.com/search?q=%22np.dtype%28np.floating%29%22&type=Code
>

In most common thing I would expect to be `dtype=np.integer` (possibly
without the `dtype` as a positional argument).
The call your search finds is nice because it must delete `np.dtype`
call.
As is, it is doing the incorrect thing so the deprecation would flush
out a bug.

- Sebastian


> On Fri, Feb 14, 2020 at 2:28 PM Sebastian Berg <
> [hidden email]> wrote:
> > Hi all,
> >
> > In https://github.com/numpy/numpy/pull/15534 I would like to start
> > deprecating creating dtypes from "abstract" scalar classes, such
> > as:
> >
> > np.dtype(np.floating) is np.dtype(np.float64)
> >
> > While, at the same time, `isinstance(np.float32, np.floating)` is
> > true.
> >
> > Right now `arr.astype(np.floating, copy=False)` and, more
> > obviously,
> > `arr.astype(np.dtype(np.floating), copy=False)` will cast a float32
> > array to float64.
> >
> > I think we should deprecate this, to consistently enable that in
> > the
> > future `dtype=np.floating` may choose to not cast a float32 array.
> > Of
> > course for the `astype` call the DeprecationWarning would be
> > changed to
> > a FutureWarning before we change the result value.
> >
> > A slight (but hopefully rare) annoyance is that `np.integer` might
> > be
> > used since it reads fairly well compared to `np.int_`. The large
> > upstream packages such as SciPy or astropy seem to be clean in this
> > regard, though (at least almost clean).
> >
> > Does anyone think this is a bad idea? To me these deprecations seem
> > fairly straight forward, possibly flush out bugs/unintended
> > behaviour,
> > and necessary for consistent future behaviour. (More similar ones
> > may
> > have to follow).
> >
> > If there is some, but not much, hesitation, I can also add this to
> > the
> > NEP 41 draft. Although I currently feel it is the right thing to do
> > even if we never had any new dtypes.
> >
> > - Sebastian
> > _______________________________________________
> > NumPy-Discussion mailing list
> > [hidden email]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
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: Py-API: Deprecate `np.dtype(np.floating)` and similar dtype creation

Nathan

On Fri, Feb 14, 2020 at 2:45 PM Sebastian Berg <[hidden email]> wrote:
On Fri, 2020-02-14 at 14:39 -0700, Nathan wrote:
> For what it's worth, github search only finds two instances of this
> usage:
>
> https://github.com/search?q=%22np.dtype%28np.floating%29%22&type=Code
>

In most common thing I would expect to be `dtype=np.integer` (possibly
without the `dtype` as a positional argument).
The call your search finds is nice because it must delete `np.dtype`
call.
As is, it is doing the incorrect thing so the deprecation would flush
out a bug.

- Sebastian


> On Fri, Feb 14, 2020 at 2:28 PM Sebastian Berg <
> [hidden email]> wrote:
> > Hi all,
> >
> > In https://github.com/numpy/numpy/pull/15534 I would like to start
> > deprecating creating dtypes from "abstract" scalar classes, such
> > as:
> >
> > np.dtype(np.floating) is np.dtype(np.float64)
> >
> > While, at the same time, `isinstance(np.float32, np.floating)` is
> > true.
> >
> > Right now `arr.astype(np.floating, copy=False)` and, more
> > obviously,
> > `arr.astype(np.dtype(np.floating), copy=False)` will cast a float32
> > array to float64.
> >
> > I think we should deprecate this, to consistently enable that in
> > the
> > future `dtype=np.floating` may choose to not cast a float32 array.
> > Of
> > course for the `astype` call the DeprecationWarning would be
> > changed to
> > a FutureWarning before we change the result value.
> >
> > A slight (but hopefully rare) annoyance is that `np.integer` might
> > be
> > used since it reads fairly well compared to `np.int_`. The large
> > upstream packages such as SciPy or astropy seem to be clean in this
> > regard, though (at least almost clean).
> >
> > Does anyone think this is a bad idea? To me these deprecations seem
> > fairly straight forward, possibly flush out bugs/unintended
> > behaviour,
> > and necessary for consistent future behaviour. (More similar ones
> > may
> > have to follow).
> >
> > If there is some, but not much, hesitation, I can also add this to
> > the
> > NEP 41 draft. Although I currently feel it is the right thing to do
> > even if we never had any new dtypes.
> >
> > - Sebastian
> > _______________________________________________
> > NumPy-Discussion mailing list
> > [hidden email]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

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