Been using numpy in it's various forms since like 2005. burned on int, int_ just today with boost.python / ndarray conversions and a number of times before that. intc being C's int!? Didn't even know it existed till today. This isn't the first time, esp with float. Bool is actually expected for me and I'd prefer it stay 1 byte for storage efficiency - I'll use a long if I want it machine word wide.
This really needs changing though. scientific researchers don't catch this subtlety and expect it to be just like the c and matlab types they know a little about. I can't even keep it straight in all circumstances, how can I expect them to? This makes all the newcomers face the same pain and introduce more bugs into otherwise good code. +1 Change it now like ripping off a bandaid. Match C11/C++11 types and solve much pain past present and future in exchange for a few lashings for the remainder of the year. Thankfully stdint like types have existed for quite some times so protocol descriptions have been correct most of the time. -Jason On Fri, Jul 24, 2015 at 8:51 AM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: > On 07/23/2015 04:29 AM, Nathaniel Smith wrote: > > Hi all, > > > > So one of the things exposed in the numpy namespace are objects called > > np.int > > np.float > > np.bool > > etc. > > > > These are commonly used -- in fact, just yesterday on another project > > I saw a senior person reviewing a pull request instruct a more junior > > person that they should use np.float instead of float or np.float64. > > But AFAICT everyone who is actually using them is doing this based on > > a very easy-to-fall-for misconception, i.e., that these objects have > > something to do with numpy. > > I don't see the issue. They are just aliases so how is np.float worse > than just float? > Too me this does not seem worth the bother of deprecation. > An argument could be made for deprecating creating dtypes from python > builtin types as they are ambiguous (C float != python float) and > platform dependent. E.g. dtype=int is just an endless source of bugs. > But this is also so invasive that the deprecation would never be > completed and just be a bother to everyone. > > So -1 from me. > > > > > > P.S.: using metamodule.py also gives us the option of making > > np.testing lazily imported, which last time this came up was > > benchmarked to improve numpy's import speed by ~35% [1] -- not too bad > > given that most production code will never touch np.testing. But this > > is just a teaser postscript; I'm not proposing that we actually do > > this at this time :-). > > > > [1] > http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063147.html > > > > I doubt these numbers from 2012 are still correct. When this was last > profiled last year the import there were two main offenders, add_docs > and np.polynomial. Both have been fixed in 1.9. I don't recall > np.testing even showing up. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
