[Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?
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. In fact they are just aliases for the regular builtin Python types: 'int', 'float', 'bool', etc. NumPy *does have* special numpy-specific types -- but these are called np.int_, np.float_, np.bool_, etc. Apparently they were set up this way back in numpy 0.something, as a backwards compatibility (!) hack: https://github.com/numpy/numpy/pull/6103#issuecomment-123801937 Now, 10+ years later, they continue to confuse people on a regular, ongoing basis, and new users are still being taught misleading facts about them. I suggest that we should deprecate them, with no fixed schedule for actually removing them. (I have no idea if/when people will actually stop using them to the point that we can get away with removing them entirely, but in the mean time we should at least be publicizing that any code which is using them is almost certainly based on a misunderstanding.) The technical challenge here is that historically it has simply been impossible to deprecate a global constant like this without using version-specific hacks or accepting unacceptable slowdowns on every attribute access. But, python 3.5 finally adds the necessary machinery to do this in a future-proof way, so now it can be done safely across all versions of Python that we care about, including future unreleased versions: https://github.com/njsmith/metamodule/ Hence: https://github.com/numpy/numpy/pull/6103 Thoughts? -n 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 -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 1,10 and 1.11 releases
Hi All, I plan on branching 1.10 this next weekend and the `__numpy_ufunc__` work will be pushed off to 1.11. One of the things we discussed at SciPy 2015 was the need for a faster release cycle. If we are going to manage that we need to start planning now by picking a release manager, listing the work we want done, and setting a preliminary release date. For the release manager, Jaime among others expressed an interest and I would be happy with that. Others who might be interested should add their names here. For work to be done, certainly we want to get the `__numpy_ufunc__` functionality settled. Other possibilities might be merging the ufunc module into multiarray or further cleanups of masked array. Longer term we might want to take a look at scalars and dtypes. Please add other suggestions here. I think December might be a good target date for the beta release, although the holidays have a way of messing with everyone's schedule. Thoughts? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] constructing record dtypes from the c-api
Hi folks,
The moderator for the ML approved my subscription so I can now post
this back in the numpy list rather than scipy. Apologies for the
duplicate/cross posting.
I was trying to figure out how to make a dtype for a c-struct on the
c-side and storing that in some boost python libraries I'm making.
Imagine the following c-struct, greatly simplified of course from the
real ones I need to expose:
struct datum{
double position[3];
float velocity[3];
int32_t d0;
uint64_t time_of_receipt;
};
How would you make the dtype/PyArray_Descr for this?
I have as a point of reference compound types in HDF for similar
struct descriptions (h5py makes these nearly 1:1 and converts back and
forth to dtypes and hdf5 types, it uses Cython to accomplish this) -
but I don't want to bring in hdf for this task - I'm not sure how well
the offsets would go over in that translation to h5py too.
Proper/best solutions would make use of offsetof as we insert entries
to the dtype/PyArray_Descr. It's fine if you do this in straight C -
I just need to figure out how to accomplish this in a practical way.
The language I'm working in is C++11. The end goal is probably going
to be to create a helper infrastructure to allow this to be made
automatically-ish provided implementation of a [static] visitor
pattern in C++. The idea is to make numpy compatible c++ POD types
rather than use Boost.Python wrapped proxies for every object which
will cut down on some complicated and time consuming code (both of
computer and developer) when ndarrays are what's called for.
Related - would one work with record dtypes passed to C? How would
one lookup fields and offsets within a structure?
Thanks for any advisement!
-Jason
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] difference between dtypes
Is there an explanation somewhere of what different basic dtypes mean, across platforms and python versions? np.bool8 type 'numpy.bool_' np.bool_ type 'numpy.bool_' bool type 'bool' Are there any rules and recommendations or is it all folks lore? I'm asking because my intuition picked up by osmosis might be off, and I thought https://github.com/scipy/scipy/pull/5076 is weird (i.e. counter intuitive). Deprecation warnings are always a lot of fun, especially if This log is too long to be displayed. Please reduce the verbosity of your build or download the raw log. Josef ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1,10 and 1.11 releases
i am interested but i dont know how start. can you help me about this ??? ___ 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
