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

Robert Kern robert.kern at gmail.com
Sun Dec 6 09:22:55 EST 2020


On Sun, Dec 6, 2020 at 12:52 AM Stephan Hoyer <shoyer at gmail.com> wrote:

> 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201206/239e07bd/attachment-0001.html>


More information about the NumPy-Discussion mailing list