Yeah, that seems to be more popular: https://github.com/search?q=%22dtype%3Dnp.integer%22&type=Code
On Fri, Feb 14, 2020 at 2:45 PM Sebastian Berg <sebast...@sipsolutions.net> 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 < > > sebast...@sipsolutions.net> 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 > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
