On Mon, Apr 16, 2012 at 10:38 PM, Travis Oliphant <tra...@continuum.io>wrote:
> > On Apr 16, 2012, at 11:01 PM, Charles R Harris wrote: > > > > On Mon, Apr 16, 2012 at 8:46 PM, Travis Oliphant <tra...@continuum.io>wrote: > >> >> On Apr 16, 2012, at 8:03 PM, Matthew Brett wrote: >> >> > Hi, >> > >> > On Mon, Apr 16, 2012 at 3:06 PM, Travis Oliphant <tra...@continuum.io> >> wrote: >> > >> >> I have heard from a few people that they are not excited by the growth >> of >> >> the NumPy data-structure by the 3 pointers needed to hold the >> masked-array >> >> storage. This is especially true when there is talk to potentially >> add >> >> additional attributes to the NumPy array (for labels and other >> >> meta-information). If you are willing to let us know how you feel >> about >> >> this, please speak up. >> > >> > I guess there are two questions here >> > >> > 1) Will something like the current version of masked arrays have a >> > long term future in numpy, regardless of eventual API? Most likely >> > answer - yes? >> >> I think the answer to this is yes, but it could be as a feature-filled >> sub-class (like the current numpy.ma, except in C). >> > > I think making numpy.ma a subclass of ndarray has caused all sorts of > trouble. It doesn't satisfy 'is a', rather it tries to use inheritance from > ndarray for implementation of various parts. The upshot is that almost > everything has to be overridden, so it didn't buy much. > > > This is a valid point. One could create a new object that is binary > compatible with the NumPy Array but not really a sub-class but provides the > array interface. We could keep Mark's modifications to the array > interface as well so that it can communicate a mask. > > Another place inheritance causes problems is PyUnicodeArrType inheriting from PyUnicodeType. There the difficulty is that the unicode itemsize/encoding may not match between the types. IIRC, it isn't recommended that derived classes change the itemsize. Numpy also has the different byte orderings... The Python types are sort of like virtual classes, so in some sense they are designed for inheritance. We could maybe set up some sort of parallel numpy type system with empty slots and such but we would need to decide what those slots are ahead of time. And if we got really serious, ABI backwards compatibility would break big time. <snip> Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
