[Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?
chris.barker at noaa.gov
Fri Jul 24 15:03:53 EDT 2015
On Fri, Jul 24, 2015 at 10:03 AM, Sturla Molden <sturla.molden at gmail.com>
> > I don't see the issue. They are just aliases so how is np.float worse
> > than just float?
> I have burned my fingers on it.
I must have too -- but I don't recall, because I am VERY careful about not
using np.float, no.int, etc... but I do have to constantly evangelize and
correct code others put in my code base.
This really is very, very, ugly.
we get away with np.float, because every OS/compiler that gets any regular
use has np.float == a c double, which is always 64 bit.
but, as Sturla points our, no.int being a C long is a disaster!
So +inf on deprecating this, though I have no opinion about the mechanism.
Ans sadly, it will be a long time before we can actually remove them, so
the evangelizing and code reviews will need to co continue for a long
> Since np.double is a C double I assumed np.float is a C float. It is not.
> np.int has the same problem by being a C long. Pure evil. Most users of
> NumPy probably expect the np.foobar dtype to map to the corresponding
> foobar C type. This is actually inconsistent and plain dangerous.
> It would be much better if dtype=float meant Python float, dtype=np.float
> meant C float, dtype=int meant Python int, and dtype=np.int meant C int.
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion