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

[Chris Barker]

On Fri, Jul 24, 2015 at 10:03 AM, Sturla Molden <sturla.molden at 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 at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150724/34634b41/attachment.html>