[Numpy-discussion] np.{bool,float,int} deprecation

[Stephan Hoyer]

On Sat, Dec 5, 2020 at 9:24 PM Mark Harfouche <mark.harfouche at gmail.com>
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.

This is a general feature for deprecations: it's much safer to remove
functionality than it is to change behavior.

So on the whole, I think this is the right call.

>
> On Sat, Dec 5, 2020 at 10:14 PM Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Sat, Dec 5, 2020 at 4:31 PM Juan Nunez-Iglesias <jni at fastmail.com>
>> 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* :)
>>
>> Chuck
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201205/335055c4/attachment.html>