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

[David Ascher]

On Fri, 3 Sep 1999, Konrad Hinsen wrote:

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

Understood.  

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

I don't know.  Given the way the CAPI stuff works, it might be nontrivial
(the subclass is defined at Python runtime, so the CAPI struct has to be
modified then).  It's worth investigating.

Alternatively, we could eliminate the subclass -- this should return
things to a backwards-compatible state. Currently, all the subclass does
is provide a place for the 'setting' of the array w/ a mask array.  It's
not enough currently to justify breaking backwards compatibility.  It was
my hope however that we could expand on that feature to provide the
gather/scatter functionality in Python, which I believe would be a very
significant feature, which is hard to do in C.  

Whether we make the C modules return an 'official' subclass or remove that
subclass altogether, we still have a situation where there is no way to
define a subclass the instances of which are usable in C modules, if a
type equality test is used.  This means that any such subclass will have
to be 'cast' before any call to a C extension module is made.  Ugh.

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

Indeed.  I agree it's a problem.  I'm not sure how big of a problem it is.

--david