On Sun, Dec 6, 2020 at 12:52 AM Stephan Hoyer <sho...@gmail.com> wrote:
> On Sat, Dec 5, 2020 at 9:24 PM Mark Harfouche <mark.harfou...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
