DEP: Deprecate numpy.linalg.lapack_lite module#32015
Conversation
50acb4c to
2b7853c
Compare
jorenham
left a comment
jorenham
left a comment
There was a problem hiding this comment.
it would be nice if we could slap some @typing_extensions.deprecated onto the functions in https://github.com/numpy/numpy/blob/cda64f0cf4584aa9e735d46ba27874296501333a/numpy/linalg/lapack_lite.pyii . That way static type-checkers will warn you if you use it at type-check-time.
|
Thanks for pointing that out I was unaware of |
jorenham
left a comment
jorenham
left a comment
There was a problem hiding this comment.
stub changes look good; thanks 👍
| info: int, # out | ||
| ) -> _DORGQR: ... | ||
|
|
||
| @deprecated("The numpy.linalg.lapack_lite module is deprecated and will be removed in a future release. It is an internal implementation detail of numpy.linalg.") |
There was a problem hiding this comment.
Can these deprecation warnings suggest what users should do instead?
See https://github.com/search?q=%22import+lapack_lite%22&type=code for a large number of real-world users of the lapack_lite module. Do any of the uses in my search hit these new warnings? What should they do when they see the warning.
There was a problem hiding this comment.
If you filter out all of numpy's own sources in site-packages and stuff, then it's really not that much (152 hits):
There was a problem hiding this comment.
Even there a lot seem just the numpy source. It's a bit unclear I looked at a few:
- 2 were importing scipy, so I think they can use the scipy lapack exposure if they really want the "low-level" feel?
- one seemed to pull it in to load math so's but loading
numpy.linalgshould do that, but not sure this one is weird... - one actually patched
numpy.linalg.lapack_literather than importing it. - One was some super outdated chunk of code, I wouldn't worry about.
Could scan more, but I would think it's fine dozens of users and it seems unlikely many don't have better alternatives (i.e. scipy).
That said, pointing to scipy for it's low-level lapack exposure probably makes sense?
|
If there are people using this module for real code, then the whole premise of this issue and PR are less correct ( i.e. wrong) and we shouldn’t deprecate it. |
rgommers
left a comment
rgommers
left a comment
There was a problem hiding this comment.
Deprecating LGTM, this isn't meant to be public. One test should be removed before merging.
… and remove subprocess test
There was a problem hiding this comment.
I asked an AI model to search for open-source uses of this module and it found two cases that aren't covered by the advice here:
- astra-toolbox/astra-toolbox: imports numpy.linalg.lapack_lite from C++ purely as a RTLD_DEEPBIND side-effect to stop MATLAB's MKL from clashing with numpy's LAPACK. It calls no routine at all.
- BLAS/Fortran introspection recipes — e.g. simomarsili/ndd uses
numpy.linalg.lapack_lite.__file__to locate the .so and run ldd on it; the _ilp64 attribute is used elsewhere to detect 64-bit BLAS.
The former could use numpy.linalg._umath_linalg instead. I'm not sure if we need to explicitly document that though because it's an unusual thing to do. Maybe one of us could send in a PR to astra-toolbox and reference this PR?
The latter could use np.show_config() instead. We should probably explicitly suggest np.show_confg() in the deprecation warning for people who are using the module for introspection.
6 participants
PR summary
As titled, based on: #31928 (comment)
Note:
If a user simply
import numpy.linalg.lapack_liteit will not give warning, it will warn only if used in test (run via pytest) or with-Wflag with python3/python.CC: @seberg @mattip
AI Disclosure
To write release note - it LGTM but someone please check it again. And to find the best way to write test for module dep.