On Fri, Jul 24, 2015 at 10:03 AM, Sturla Molden <[email protected]> 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 > [email protected] > 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 [email protected]
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
