[Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

Nathaniel Smith njs at pobox.com
Wed Jul 22 22:29:19 EDT 2015


Hi all,

So one of the things exposed in the numpy namespace are objects called
  np.int
  np.float
  np.bool
etc.

These are commonly used -- in fact, just yesterday on another project
I saw a senior person reviewing a pull request instruct a more junior
person that they should use np.float instead of float or np.float64.
But AFAICT everyone who is actually using them is doing this based on
a very easy-to-fall-for misconception, i.e., that these objects have
something to do with numpy.

In fact they are just aliases for the regular builtin Python types:
'int', 'float', 'bool', etc. NumPy *does have* special numpy-specific
types -- but these are called np.int_, np.float_, np.bool_, etc.

Apparently they were set up this way back in numpy 0.something, as a
backwards compatibility (!) hack:
   https://github.com/numpy/numpy/pull/6103#issuecomment-123801937

Now, 10+ years later, they continue to confuse people on a regular,
ongoing basis, and new users are still being taught misleading "facts"
about them. I suggest that we should deprecate them, with no fixed
schedule for actually removing them. (I have no idea if/when people
will actually stop using them to the point that we can get away with
removing them entirely, but in the mean time we should at least be
publicizing that any code which is using them is almost certainly
based on a misunderstanding.)

The technical challenge here is that historically it has simply been
impossible to deprecate a global constant like this without using
version-specific hacks or accepting unacceptable slowdowns on every
attribute access. But, python 3.5 finally adds the necessary machinery
to do this in a future-proof way, so now it can be done safely across
all versions of Python that we care about, including future unreleased
versions:
  https://github.com/njsmith/metamodule/

Hence:
  https://github.com/numpy/numpy/pull/6103

Thoughts?

-n

P.S.: using metamodule.py also gives us the option of making
np.testing lazily imported, which last time this came up was
benchmarked to improve numpy's import speed by ~35% [1] -- not too bad
given that most production code will never touch np.testing. But this
is just a teaser postscript; I'm not proposing that we actually do
this at this time :-).

[1] http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063147.html

-- 
Nathaniel J. Smith -- http://vorpus.org



More information about the NumPy-Discussion mailing list