NEP 15: Merging multiarray and umath #10704
Conversation
|
Cycling PR to attempt to fix circleci weirdness. |
f01a609 to
49592ab
Compare
|
I'd like to just merge this, but then there is no place for discussion. What process is proposed for updating/discussing NEP proposals? |
|
There's a greater evil than |
|
There is a similar dichotomy with |
|
My understanding there is that |
|
OTOH, numpy.linalg.lapack_lite contains non-ufunc wrappers for a few
LAPACK routines. I guess the only reason for its existence is that the
work for porting those to gufuncs was not done yet.
|
| have internal API that's visible to everything inside the same | ||
| extension module, or you can have a public API that everyone can use; | ||
| you can't have an API that's visible to multiple extension modules | ||
| inside numpy, but not to external users. |
There was a problem hiding this comment.
Not an argument against doing this NEP -- but there would be nothing stopping you from having two PyCapsule tables -- one for the public ABI and the other for private. Both would be technically public and some bad actors would use and come to rely on the private, but it would be easier to say 'told you so' to those folks.
| ``numpy/core/src/private/``, which now contains a bunch of files which | ||
| are ``#include``\d twice, once into ``multiarray`` and once into | ||
| ``umath``. This is pretty gross, and is purely a workaround for these | ||
| being separate C extensions. |
There was a problem hiding this comment.
npymath is also included in both extension modules.
|
#10703 has been merged, is there anything blocking this from a merge? |
| but we can make one or both of these modules be tiny shims that simply | ||
| re-export the magic API object from where-ever it's actually defined. | ||
| (See ``numpy/core/code_generators/generate_{numpy,ufunc}_api.py`` for | ||
| details of how these imports work.) |
There was a problem hiding this comment.
Is it a requirement that we still have c-extension modules named numpy.core.{umath, multiarray} or can they be pure python wrappers around the single c-extension module (call it numpy.core._multiarray)? Can't the _ARRAY_APIand _UFUNC_API be exported from the same shared object?
There was a problem hiding this comment.
Nothing prevents pure-python wrapper files iiuc.
4c4716e to
3ef1431
Compare
Note to self: still need to add this to index.rst, but maybe better to
wait until after #10703 is merged.