Re: [Numpy-discussion] np.{bool,float,int} deprecation
On Sun, Dec 6, 2020 at 12:52 AM Stephan Hoyer wrote: > On Sat, Dec 5, 2020 at 9:24 PM Mark Harfouche > wrote: > >> If the answer is to deprecate >> >> np.int(1) == int(1) >> >> then one can add a warning to the __init__ of the np.int class, but >> continue to subclass the python int class. >> >> It just doesn’t seem worthwhile to to stop people from using dtype=np.int, >> which seem to read: >> >> “I want this to be a numpy integer, not necessarily a python integer”. >> > The problem is that there is assuredly code that inadvertently relies upon > this (mis)feature. > > If we change the behavior of np.int() to create np.int64() objects > instead of int() objects, it is likely to result in breaking some user > code. Even with a prior warning, this breakage may be surprising and very > hard to track down. In contrast, it's much safer to simply remove np.int > entirely, because if users ignore the deprecation they end up with an error. > FWIW (and IIRC), *this* was the original misfeature. `np.int`, `np.bool`, and `np.float` were aliases for their corresponding default scalar types in the first numpy releases. However, too many people were doing `from numpy import *` and covering up the builtins. We renamed these aliases with trailing underscores to avoid that problem, but too many people (even in those early days) still had uses of `dtype=np.int`. Making `np.int is int` was the backwards-compatibility hack. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.{bool,float,int} deprecation
On Sat, 2020-12-05 at 20:12 -0700, Charles R Harris wrote:
> On Sat, Dec 5, 2020 at 4:31 PM Juan Nunez-Iglesias
> wrote:
>
> > Hi all,
> >
> > At the prodding [1] of Sebastian, I’m starting a discussion on the
> > decision to deprecate np.{bool,float,int}. This deprecation broke
> > our
> > prerelease testing in scikit-image (which, hooray for rcs!), and
> > resulted
> > in a large amount of code churn to fix [2].
> >
> > To be honest, I do think *some* sort of deprecation is needed,
> > because for
> > the longest time I thought that np.float was what np.float_
> > actually is. I
> > think it would be worthwhile to move to *that*, though it’s an even
> > more
> > invasive deprecation than the currently proposed one. Writing `x =
> > np.zeros(5, dtype=int)` is somewhat magical, because someone with a
> > strict
> > typing mindset (there’s an increasing number!) might expect that
> > this is an
> > array of pointers to Python ints. This is why I’ve always preferred
> > to
> > write `dtype=np.int`, resulting in the current code churn.
> >
> > I don’t know what the best answer is, just sparking the discussion
> > Sebastian wants to see. ;) For skimage we’ve already merged a fix
> > (even if
> > it is one of dubious quality, as Stéfan points out [3] ;), so I
> > don’t have
> > too much stake in the outcome.
> >
> > Juan.
> >
> > [1]:
> > https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739334463
> > [2]: https://github.com/scikit-image/scikit-image/pull/5103
> > [3]:
> > https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739368765
> >
>
> I checked pandas and astropy and both have several uses of the
> deprecated
> types but should be easy to fix. I suppose the question is if we want
> to
> make them fix things *right now* :)
>
The reason why I thought it might be good to bring this up again is
that I am not sure clear on how painful the deprecation is; which
should be weighed against the benefit. And the benefit here is only
moderate.
Thus, with the things now in and a few more people exposed to it, if
anyone thinks its a bad idea or that we should delay, I am all ears.
Cheers,
Sebastian
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rules for argument parsing/forwarding in __array_function__ and __array_ufunc__
On Sat, 2020-12-05 at 22:05 -0800, Stephan Hoyer wrote: > On Wed, Dec 2, 2020 at 3:39 PM Sebastian Berg < > sebast...@sipsolutions.net> > wrote: > > > 1. If an argument is invalid in NumPy it is considered and error. > >For example: > > > >np.log(arr, my_weird_argument=True) > > > >is always an error even if the `__array_function__` > > implementation > >of `arr` would support it. > >NEP 18 explicitly says that allowing forwarding could be done, > > but > >will not be done at this time. > > > > From my perspective, this is a good thing: it ensures that NumPy's > API is > only used for features that exist in NumPy. Otherwise I can imagine > causing > considerable confusion. > > If you want to use my_weird_argument, you can call > my_weird_library.log() > instead. > > > > 2. Arguments must only be forwarded if they are passed in: > > > >np.mean(cupy_array) > > > >ends up as `cupy.mean(cupy_array)` and not: > > > >cupy.mean(cupy_array, axis=None, dtype=None, out=None, > > keepdims=False, where=True) > > > >meaning that CuPy does not need to implement all of those kwargs > > and > >NumPy can add new ones without breaking anyones code. > > > > My reasoning here was two-fold: > 1. To avoid the unfortunate situation for functions like np.mean(), > where > NumPy jumps through considerable hoops to avoid passing extra > arguments in > an ad-hoc way to preserve backwards compatibility > 2. To make it easy for a library to implement "incomplete" versions > of > NumPy's API, by simply omitting arguments. > > The idea was that NumPy's API is open to partial implementations, but > not > extension. > Indeed, changing this allows inlining in Python easier (because you don't need to use `**kwargs` to be able to know which arguments were not passed). I guess the alternative is to force everyone to keep up, but you are of course allowed to raise a NotImplementedError (which is actually nicer for users, probably). > > > 3. NumPy should not check the *validity* of the arguments. For > > example: > >`np.add.reduce(xarray, axis="long")` should probably work in > > xarray. > >(`xarray.DataArray` does not actually implement the above.) > >But a string cannot be used as an axis in NumPy. > > > > I don't think libraries should be encouraged to abuse NumPy's API to > mean > something else. Certainly I would not use this in xarray :). > > If we could check the validity of arguments cheaply, that would be > fine by > me. But I didn't think it was worth adding overhead to every function > call. > Perhaps type annotations could be relied on for these sorts of > checks? I am > pretty happy considering not checking the validity of arguments to be > an > implementation detail for now. The current implementation of __array_function__ makes this hard, because it assumes the call graph is: array_funciton_implementation(...): impl = find_implementation() # impl may be the default return impl() Unlike for __array_ufunc__ where it is: ufunc.__call__(*args, **kwargs): if needs_to_defer(args, kwargs): return defered_result() If you assume that NumPy is the main consumer, especially on the C- side, validating the arguments (e.g. integer axis, NumPy dtypes) can make things more comfortable. "inlining" the dispatching as the second case, makes things quite a bit more comfortable, but is not necessary. However, it requires a small change to the default __array_function__ (i.e. you have to change the meaning to "defaul __array_function__" is the same as no array function.) Cheers, Sebastian > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
