On Fri, Jul 24, 2015 at 10:03 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
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 time... -Chris
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.
Sturla
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Christopher Barker, Ph.D. Oceanographer 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@noaa.gov