[Numpy-discussion] NA-mask interactions with existing C code

[Travis Oliphant]

>> 
>> See my post in the other thread for my proposal to add a flag that allows users to switch between the Python side default being ndarray's or ndmasked, but they are different types at the C-level.    The proposal so far does not specify whether or not ndarray or ndmasked is a subclass of the other.   Given the history of numpy.ma and the fact that it makes sense on the C-level, I would lean toward ndmasked being a sub-class of ndarray --- thus a C-user would have to do a PyArray_CheckExact to ensure they are getting a base Python Array Object --- which they would have to do anyway because numpy.ma arrays also pass PyArray_Check.
> 
> Making it a subclass means existing Cython code is not catered for, as 
> PyObject_TypeCheck is used.

That is good to know.   My understanding, though, is that in this case Cython code will already be passing numpy.ma (which is a sub-class of ndarray) as an array and be ignoring its mask already.     If that is the case, then this wouldn't fundamentally change anything for you.   

My proposal improves the situation for a few groups:

	1) C-API Users that are not used to dealing with masks at all in downstream code 
	2) C Users who use an exact check (PyArray_CheckExact or "O!" in PyArg_ParseTuple). 
	3) C Users who don't want all arrays to now have masks attached
	

> 
> Is there a advantage for users by making it a subclass? Nobody is saying 
> you couldn't 'inherit' the struct (make the ndmask struct be castable to 
> a PyArrayObject*) even if that is not declared in the Python type object.

I don't really think there is an advantage of making it a subclass --- except numpy.ma is already a subclass and it might make it easier to write it's API on top of ndmasked.  

Definitely the first part of the ndmasked struct could be castable to a PyArrayObject (I would want to add room in that case to the PyArrayObject for at least one additional AuxData pointer that could hold label information). 

-Travis


> 
> Dag
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion