Nathaniel Smith wrote: > IME > it's important for the default behavior to be to fail loudly when > things are wonky, not to silently patch them up, possibly > incorrectly!)
+1 for default behavior to fail, raise errors, or return "unknown values" is these situations. Though that behavior should be over-ridable with a flag or addition functions (like nan-sum) Robert Kern wrote: > How your proposal > improves on the status quo, i.e. numpy.ma. I've thought for years that masked arrays should be better integrated with numpy -- it seems there is a lot of code duplication and upkeep required to keep masked arrays working as much like regular arrays as possible. Particularly having third-party code work with them. And I'm not sure I can explain why, but I find myself hardly ever using masked arrays -- it just feels like added complication to use them -- I tend to work with floats and use NaN instead, even though it's often not as good an option. Gael Varoquaux wrote: > Right now, the numpy array can be seen as an extension of the C array, > basically a pointer, a data type, and a shape (and strides). This enables > easy sharing with libraries that have not been written with numpy in > mind. Isn't that what the PEP 3118 extended buffer protocol is supposed to be for? Anyway, good stuff! -Chris -- 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
