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