[Matrix-SIG] An area where the C-API for NumPy 1.12 is not 100% compatible

[David Ascher]

> I'd prefer a fix in NumPy, if possible. Without looking at any code
> at all, could one rename the type of the "fundamental" array object
> to something else and use PyArray_Type for the subclass? Assuming
> of course that subclasses have proper type objects.

Hmm.  The problem is that currently all of the internal (C) code creates
objects of the fundamental data type, and all the .py code creates objects
of a subclass of said type.  I think having this duality is in fact a very
good thing, as it means we can add features to the standard data type
which Python users manipulate w/o messing w/ C code. 

Whether the fundamental data type (currently PyArray_Type) or the subclass
(Array) is used for a 'type equality' test, some code will break,
depending on whether it gets its arguments from a 'core' function or a
python function.  I think the proper check is to do a subclass test
instead, which is what PyArray_Check() does.  Alas, "O!" is unable to do
that right now.  I suppose we could slip a PyArg_ParseTuple() which did it
in arrayobject.h.  Nasty hack, though.  (the 'right' solution will have to
wait for subclassability of Python types in the Python core, which isn't
planned until 2.0).

Any other ideas?

--david