>> 
>> 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@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

Reply via email to