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

Julian Taylor jtaylor.debian at googlemail.com
Fri Jul 24 11:51:54 EDT 2015

On 07/23/2015 04:29 AM, Nathaniel Smith wrote:
> 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.

I don't see the issue. They are just aliases so how is np.float worse 
than just float?
Too me this does not seem worth the bother of deprecation.
An argument could be made for deprecating creating dtypes from python 
builtin types as they are ambiguous (C float != python float) and 
platform dependent. E.g. dtype=int is just an endless source of bugs.
But this is also so invasive that the deprecation would never be 
completed and just be a bother to everyone.

So -1 from me.

> 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

I doubt these numbers from 2012 are still correct. When this was last 
profiled last year the import there were two main offenders, add_docs 
and np.polynomial. Both have been fixed in 1.9. I don't recall 
np.testing even showing up.

More information about the NumPy-Discussion mailing list