On Fri, Apr 27, 2012 at 11:32 AM, Richard Hattersley <[email protected]> wrote: > I know used a somewhat jokey tone in my original posting, but fundamentally > it was a serious question concerning a live topic. So I'm curious about the > lack of response. Has this all been covered before? > > Sorry if I'm being too impatient!
That's fine, I know I did read it, but I wasn't sure what to make of it to respond :-) > On 25 April 2012 16:58, Richard Hattersley <[email protected]> wrote: >> >> The masked array discussions have brought up all sorts of interesting >> topics - too many to usefully list here - but there's one aspect I haven't >> spotted yet. Perhaps that's because it's flat out wrong, or crazy, or just >> too awkward to be helpful. But ... >> >> Shouldn't masked arrays (MA) be a superclass of the plain-old-array (POA)? >> >> In the library I'm working on, the introduction of MAs (via numpy.ma) >> required us to sweep through the library and make a fair few changes. That's >> not the sort of thing one would normally expect from the introduction of a >> subclass. >> >> Putting aside the ABI issue, would it help downstream API compatibility if >> the POA was a subclass of the MA? Code that's expecting/casting-to a POA >> might continue to work and, where appropriate, could be upgraded in their >> own time to accept MAs. This makes a certain amount of sense from a traditional OO modeling perspective, where classes are supposed to refer to sets of objects and subclasses are subsets and superclasses are supersets. This is the property that's needed to guarantee that if A is a subclass of B, then any code that expects a B can also handle an A, since all A's are B's, which is what you need if you're doing type-checking or type-based dispatch. And indeed, from this perspective, MAs are a superclass of POAs, because for every POA there's a equivalent MA (the one with the mask set to all-true), but not vice-versa. But, that model of OO doesn't have much connection to Python. In Python's semantics, classes are almost irrelevant; they're mostly just some convenience tools for putting together the objects you want, and what really matters is the behavior of each object (the famous "duck typing"). You can call isinstance() if you want, but it's just an ordinary function that looks at some attributes on an object; the only magic involved is that some of those attributes have underscores in their name. In Python, subclassing mostly does two things: (1) it's a quick way to define set up a class that's similar to another class (though this is a worse idea than it looks -- you're basically doing 'from other_class import *' with all the usual tight-coupling problems that 'import *' brings). (2) When writing Python objects at the C level, subclassing lets you achieve memory layout compatibility (which is important because C does *not* do duck typing), and it lets you add new fields to a C struct. So at this level, MAs are a subclass of POAs, because MAs have an extra field that POAs don't... So I don't know what to think about subclasses/superclasses here, because they're such confusing and contradictory concepts that it's hard to tell what the actual resulting API semantics would be. - N _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
