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

[Konrad Hinsen]

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

The C module would have to import the Python module, and that sounds
like a nice case of circular imports... Not so simple indeed...

> Alternatively, we could eliminate the subclass -- this should return
> things to a backwards-compatible state. Currently, all the subclass does

That might be the best immediate solution, until we find a better one.

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

That should be a general problem with extension classes, and perhaps
one should look for a general solution. Ideally, PyArg_ParseTuple()
(or a similar function provided by the ExtensionClass module) would
offer both direct type comparison and subclass checks. Then of course
C modules would have to be adapted - but I'd prefer to impose this
only once, when a definite solution is available.

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