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

[Konrad Hinsen]

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

Meaning that there are two array types which behave differently,
depending on where the array was created? Sounds like a developer's
nightmare to me. One of the strong points of Python is being able
to do the same thing in Python or C without making any difference to
the outside world. I'd like to keep that for arrays as well.

Is there any reason why C modules can't return the subclass as well?

> 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

But comparing type objects is a common approach in C extension
modules; I wouldn't be surprised if there was some code out there that
doesn't use the type check macro but a direct comparison. I am not
saying that I support this kind of style, but it was never explicitly
declared unsafe, and used work perfectly well.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------